Re: 3D graphic cards
I thought most of the GATOS stuff had been merged into 4.3. At least I have had no problems with Xv on my Radeon 7000 with XFree86 4.3.0 and I seem to recall that support was claimed for all Radeons except, perhaps the 9500. Perhaps for other cards, but there's still no native Xv support for Mach64-based adaptors (such as the Rage Mobility M1 fitted to many laptops) in 4.3, you need the GATOS drivers for this. (The M6 fitted to many slighly later laptops is a completely different chipset that uses the Radeon driver, IIRC. Love it when Marketing pull BS like this) Cheers, AS pgp0.pgp Description: PGP signature
Re: 3D graphic cards
You might want to try the Gatos drivers from http://gatos.sourceforge.net/ . With this driver, I got the ATi chipset in my laptop working with Xv support. I've just visited the page. Looks promising, indeed, but I'm a bit puzzled. One binary release for FreeBSD _and_ Linux? Yes, and most other Intel x86-based OS's. The X server contains support for on-demand, OS- and even binary-format independent module loading. See: http://www.xfree86.org/~dawes/4.3.0/DESIGN17.html#65 The GATOS binary drivers (originally compiled for Linux) have been working for me on my ATI-based laptop for a long time (multiple versions, natch), never a problem. I'm told they compile fine, but I've never bothered. Cheers, AS pgp0.pgp Description: PGP signature
Re: WEIRD! div() broken on -CURRENT?
Actually only a 4 years -- the a.out-ELF cut over broke the 5-10 years of binary compatibility. As mentioned at http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html we really made a mistake when we did the a.out-ELF cut over thus resulting in us breaking the i386 ELF ABI. I have wondered in the past how this affects is with sharing XFree86 binary modules with Linux. Hmm, I've been running GATOS binary modules built for Linux to provide XV support for an ATI Mobility Pro LY for some time (at least 6-8 months and some 4-5 different experimental versions so far, all have worked great): andy@tureg[39]- xvinfo X-Video Extension version 2.2 screen #0 Adaptor #0: ATI mach64 Video Overlay number of ports: 1 port base: 55 operations supported: PutImage supported visuals: depth 16, visualID 0x23 depth 16, visualID 0x24 depth 16, visualID 0x25 depth 16, visualID 0x26 number of attributes: 17 XV_DEVICE_ID (range 0 to -1) client gettable attribute (current value is 86) XV_LOCATION_ID (range 0 to -1) client gettable attribute (current value is 87) XV_INSTANCE_ID (range 0 to -1) client gettable attribute (current value is 88) XV_SET_DEFAULTS (range 0 to 1) client settable attribute XV_AUTOPAINT_COLORKEY (range 0 to 1) client settable attribute client gettable attribute (current value is 1) XV_COLORKEY (range 0 to -1) client settable attribute client gettable attribute (current value is 6208) XV_DOUBLE_BUFFER (range 0 to 1) client settable attribute client gettable attribute (current value is 1) XV_ENCODING (range 0 to 12) client settable attribute client gettable attribute (current value is 1) XV_FREQ (range 0 to -1) client settable attribute client gettable attribute (current value is 1000) XV_TUNER_STATUS (range -1000 to 1000) client gettable attribute (current value is 4) XV_MUTE (range 0 to 1) client settable attribute client gettable attribute (current value is 1) XV_VOLUME (range -1000 to 1000) client settable attribute client gettable attribute (current value is -1000) XV_BRIGHTNESS (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) XV_CONTRAST (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) XV_SATURATION (range -1000 to 1000) client settable attribute client gettable attribute (current value is 16) XV_COLOR (range -1000 to 1000) client settable attribute client gettable attribute (current value is 16) XV_HUE (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 2048 x 2048 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x59565955 (UYVY) guid: 55595659--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) Seems to work pretty well from a stability POV, no issues that I could point at the module for. And certainly the hardware scaling and color transforms work way better than they do without the module ;-) Cheers, AS msg49272/pgp0.pgp Description: PGP signature
Re: 80386 out of GENERIC
12MB? The last time I tried on a 16MB machine, it core dumped because it ran out of memory. I had to put 24MB in the machine before it would work (I couldn't try 20MB due to onhand SIMMs). Uhh, I think we should move forward, like everyone else says. I mean, I don't throw computers away, but all my 486's have died now, RIP... Having said that, to the best of my knowledge, there's still a scavenged P-90 with two 3Com NIC's bridging two LANs and acting as an internal router between them after two companies (one of which I used to work at) merged 5 years ago, and they wanted to access the private Frame Relay from their own LAN. It's running FreeBSD 2.2.x on an 80MB HDD with no swap (it was a *very* tight squeeze), and got upgraded to 5MB of RAM (it was installed with 4MB) after the guy running it decided to enable NIS and found it wouldn't work without a little more memory... Heh. I guess that's progress for ya. :) Cheers, AS msg48889/pgp0.pgp Description: PGP signature
Re: burncd/cdcontrol
On Sat, 26 Oct 2002, Julian Elischer wrote: what would it take to allow burncd to work on SCSI devices.? You got it backwards -- is atapicam complete enough to work reliably with cdrecord? I don't see why it shouldn't work on -CURRENT. It works fine for me on -STABLE, for oh, months and months - I've burnt 50 CDs 8x on an IDE combo DVD/CDRW laptop drive[0]. Currently on -STABLE with ATAPI-CAM patches from August 20th. With cdrecord[1]. 1 coaster (experimenting with -overburn) to date. There's no reason for us to replicate a more feature-complete port in our src tree. Sure. I'm just waiting for ATAPI-CAM to get MFC'd to -STABLE. Cheers, AS [0] Which, thanks to 'atacontrol', is even hot-swappable. :) [1] Cdrecord 1.11a28 (i386-unknown-freebsd4.6) Copyright (C) 1995-2002 Jörg Schilling Using libscg version 'schily-0.6' scsibus1: 1,0,0 100) 'TEAC' 'DW-28E ' '1.0A' Removable CD-ROM Cdrecord 1.11a28 (i386-unknown-freebsd4.6) Copyright (C) 1995-2002 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 Using libscg version 'schily-0.6' atapi: 0 Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'TEAC' Identifikation : 'DW-28E ' Revision : '1.0A' Device seems to be: Generic mmc2 DVD-ROM. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R Drive buf size : 1441792 = 1408 KB FIFO size : 4194304 = 4096 KB Track 01: data 695 MB padsize: 30 KB Total size: 799 MB (79:10.30) = 356273 sectors Lout start: 799 MB (79:12/23) = 356273 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 5 Is not unrestricted Is not erasable Disk sub type: Medium Type C, low Beta category (C-) (6) ATIP start of lead in: -11640 (97:26/60) ATIP start of lead out: 359849 (79:59/74) Disk type:Long strategy type (Cyanine, AZO or similar) Manuf. index: 3 Manufacturer: CMC Magnetics Corporation Blocks total: 359849 Blocks current: 359849 Blocks remaining: 3576 Starting to write CD/DVD at speed 8 in real TAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Performing OPC... Starting new track at sector: 0 Track 01: 695 of 695 MB written (fifo 100%) 8.4x. Track 01: writing 30 KB of pad data. Track 01: Total bytes read/written: 729612288/729643008 (356271 sectors). Writing time: 607.606s Fixating... Fixating time: 33.575s cdrecord: fifo had 11493 puts and 11493 gets. cdrecord: fifo was 0 times empty and 11246 times full, min fill was 93%. msg45420/pgp0.pgp Description: PGP signature
Re: CURRENT's termcap broken
On Sat, Aug 31, 2002 at 00:04:44 +0200, Jens Schweikhardt wrote: # and midnight commander shows all with -, +, | instead of # pesudo-graphics. It seems this is the price we pay for alignment with what XFree86 ships. We don't need to pay, if entries will be _really_ corrected instead of _blindly_ updated. IMHO, it has been corrected, and was incorrect before. FWIW, this would also appear to be the opinion of the current maintainer of 'xterm' for XFree86. Ache, have you read bin/41143? Regards, AS msg42324/pgp0.pgp Description: PGP signature
Re: CURRENT's termcap broken
IMHO, it has been corrected, and was incorrect before. I mean, corrected for ACS characters (pseudo-graphics), which are correct before. Read complains above. I believe that these are fixed by not using an incorrect termtype (e.g. 'xterm-color', which refers to another terminal type altogether). Ache, have you read bin/41143? To fix what you mean, just moving 'xterm-color' entry additional color capabilities directly to 'xterm' entry and making 'xterm-color' as alias to 'xterm' will be enough to fix PR. Hmmm. Except that 'xterm-color' is widely used as a cap for an older (and incompatible) termtype, as stated in the PR. And the author of xterm has widely criticised FreeBSD's incorrect handling of other attributes. To the point where he has documented the brokeness in his FAQ, and specifically advises to use the termcap supplied with 'xterm'. Again, as stated in the PR. Specifically: http://dickey.his.com/xterm/xterm.faq.html#xterm_terminfo Regards, AS msg42326/pgp0.pgp Description: PGP signature
Re: install crash on hp omnibook 6100
i'm trying to install current from cd (i took 3 different builds) to my notebook hp omnibook 6100. by booting the kernel after few lines is the machine crashing. i'm not abte to see the reason, everything goes too fast. has anybody similar situation? any ideas why? 4.6 works fine. Hi Tomas, Last time I installed -current on a 6100, having ACPI enabled would reboot the machine. Try disabling it from the boot loader, search the -STABLE archives for the ACPI causes immediate reboot thread. I don't know the current status (I couldn't get an acceptable subset of devices for my primary machine whilst travelling, so sold it on). At least one person with a 6100 persevered further with this, maybe someone else can help you with the current status or better advice? Cheers, AS msg42110/pgp0.pgp Description: PGP signature
CAM-ATAPI status?
Hi, What's the status of the CAM/ATAPI integration? Is anyone thinking of working on it? When last mentioned, it was mooted that some work needed to be done to tidy things up. Since then, it's gone very quiet - specifically, I don't seem to recall seeing any specifics about what needed to be cleaned up. Some time later (what it is now, 6 months?), it's not in the tree, and I suspect that the happy ATAPI/CAM users are either applying patches locally to keep using this useful functionality, or bemoaning the fact that FreeBSD doesn't let them use cdrecord with ATAPI CD-Rs Whilst I appreciate the need for coding standards and good-quality code, (and indeed this is a large part of my personal reasons for choosing this OS), it seems to me that this has kind of slipped through the cracks. I've been using the CAM/ATAPI patches on -STABLE for some time now, and it Just Works - I've burned quite a lot of CD-R's and CD-RW's with my internal laptop drive and the latest 'cdrecord' from ports, and neither this nor anything else on the machine appears to suffer unduly. What I'd *really* like to see is for the CAM/ATAPI stuff to go into 4.7 - it seems to me that people choose the OS for stability, performance and, let's not forget, *features*, what you can actually /do/ with the machine. Regards, AS msg41836/pgp0.pgp Description: PGP signature
Re: CAM-ATAPI status?
You'll be happy to tell them sys/dev/ata/atapi-cam.c: Revision 1.1 Fri Aug 9 20:51:53 2002 UTC (3 days, 3 hours ago) by sos Branch: MAIN Well, golly... And with improvements too! In good time for an MFC for 4.7! Awesome, no, outstanding! Thanks to all concerned, I really am very happy to be wrong! :-) Regards, AS msg41840/pgp0.pgp Description: PGP signature
Re: SCSI emulation in FreeBSD
Anybody have any idea what I need and where I can find it? http://www.cuivre.fr.eu.org/~thomas/atapicam/ Just as a datapoint, I recently applied the ATAPI/CAM patches to a -STABLE from July 10th). They applied flawlessly, compile was clean. My newly-acquired TEAC DW-28E CDR/CDRW/DVD drive now works perfectly with the SCSI cdrecord from ports. And thanks to 'atacontrol', I can even hot-swap IDE devices in and out of the laptop modular bay. This OS rocks!! Thanks to all for their efforts. I would be even happier if the ATAPI-CAM patches could finally be integrated, so I didn't have to apply them manually after each cvsup. Regards, AS msg41004/pgp0.pgp Description: PGP signature
Re: PCCARD/NEWCARD won't configure on 5.0
OK. Here we see the confluance of two problems. First, irq 0 is bogus and likely illegal per the pci spec for devices that do interrupt. Even if it isn't illegal, it is wrong wrong wrong wrong, but lots of people do it. I have a patch for -stable, but not for current. Well, the card stuff on this particular laptop Just Works under -stable - but then the sound won't get attached, which is why I'm trying to get a full house of devices under -current. Gack. The second problem is, at its base, that we're not assigning memory for this device in the pci layer. However, pccbb tries to work around that by asking the pci layer for a specific range, triggering an allocation. That allocation is failing (the third of two problems :-) because the bridge code isn't clipping the request to what's decoded, but rather rejecting it. Until problem 1 is fixed, problem is moot for you. NEWCARD doesn't have the concept of polling, which is problem number 4 of 2, so you can't do the OLDCARD trick of using ISA interupts (which NEWCARD doesn't support either, problem number 5 of 2). Gotta love one problem report hitting 5 problems all at once :-) You do? :-/ Thanks Warner. AS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI errors from xmcd
Your message dated: Tue, 21 Mar 2000 20:57:17 GMT Is this because xmcd needs updating to work with the new CAM system, or something else? You need to recompile xmcd. In that case I need to wait for the package to be updated. xmcd needs Motif, which I don't have, so I use the binary package. I find a lot of stuff which "needs" Motif (including 'xmcd') builds and works just great with Lesstif, and there's a port for that. You might like to set 'HAVE_MOTIF=yes' manually in '/etc/make.conf' after installing. :-) Something else that sometimes causes problems might be having old-as-dirt libraries kicking around from aeons ago - sometimes these seem to get used if they're present on the system, and not much cleans them out except operator intervention... Cheers, AS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Two queries [ KDE / XFree86 ]
Your message dated: Mon, 28 Feb 2000 23:49:07 EST Will Andrews wrote: One compatability problem would seem to be lack of support for the Number Nine I128 board, previously supported in 3.3.*. AOL Me too! :-) /AOL This is very disappointing, as I've got to use that board to drive my SGI 1600x1200 LCD display.. I guess I'll be using 3.3.6 a bit longer on that machine :-( I'd love to be proved wrong, but the release notes for the snapshots have been pretty silent on support for this board. *grumble* Yeh, and I'd like to know why the DGA (specifically, Direct Video) support the VMware folks kindly provided as patches for 3.3.3.1 haven't made it into 3.x yet - I've been manually patching them in ever since so that I can run 'fxtv'... Cheers, AS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of 'device awe' ?
On Tue, Feb 22, 2000 at 03:46:04PM -0700, Kenneth D. Merry wrote: On Tue, Feb 22, 2000 at 23:33:26 +0100, Jeroen Ruigrok van der Werven wrote: -On [2222 23:25], Daniel O'Connor ([EMAIL PROTECTED]) wrote: On 22-Feb-00 Jeroen Ruigrok van der Werven wrote: Should be used instead. I am so in favor of just declaring voxware dead... But the armchair generals wouldn't like that. The awe device controls the AWE's wavetable.. newpcm doesn't talk to this (yet - no idea if there are any plans) newmidi is underway... That's why I wanted to kill voxware in 4.0, would allow pcm to be used from default... Now we're stuck to the voxware crap for another release cycle until 5.0 hits the public. Voxware may be "crap", but newpcm doesn't work right for my GUS PnP. (And yep, I sent mail to the multimedia list, which got some response, and I sent mail to Cameron, which got no response.) Voxware used to work fine, way back when. Luigi's pcm code worked fine as well with my GUS PnP. Maybe it's time for me to switch back to voxware from newpcm. I'm tired of getting static every once in a while when playing sound files. I don't see any reason to get rid of voxware before newpcm is fully functional. Unfortunately for those of us who used to use 'pnp' commands in userconfig to probe/init the AWE registers, the AWE wavetable is already useless in -current. AFAIK, the AWE cannot work without this, and the cards PnPinfo seems to not include the other two registers - and if you don't probe them, then the 'awe' driver check doesn't see the EMU8000... Is there even a single person out there able to use the AWE device under Voxware in -current? My understanding is that this is no longer possible, following the removal of the 'pnp' interface in userconfig.. So, people with the AWE32, AWE daughter card or the AWE64 might as well have an original SoundBlaster 16, for all the good the EMU8000 wavetable/synth chip does them. If that is really so, then I would suggest that either: a) the 'awe' driver is now just so much cruft and should be removed. or b) FreeBSD has lost significant functionality (namely, AWE wavetable support) with the removal of the older 'pnp' interface, and this should be put back. I guess that your perspective on this really depends on whether you actually have the hardware and want to use it... For me, with an integrated Vibra 16 on the mobo, Voxware is now unusable for sound as the SoundBlaster portion is not recognised. (Again, only in -current, it all works perfectly in -stable). I /have/ to use pcm in -current, simply to play CDs (which, incidentally, works well for me)... Of course, for the time being, I have the option of using this hardware under -stable, but eventually the changes will filter through to there as well. Of more importance (to me, right now), is that -stable is not getting the benefit of the other improvements that are going on in -current. (e.g. Linux threads, SMP, NFS etc.) Cheers, AS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, tell me again why we can't read audio CDs in SCSI drives?
On Fri, Jan 07, 2000 at 02:03:29AM +0100, Karsten W. Rohrbach wrote: detection and removal (real goodd error correction) and this ones also really fast (10x speed) when youre reading on a plextor drive (such as my pxw4220t) or something else that has a native mode for extracting audio. One of the main reasons for springing the extra $$$ for a Plextor is that they (unlike most other CDDA implementations) actually got the firmware right: the beast does jitter correction in firmware, /and/ reads at near-data speeds whilst it does it. Many CD drives with buggy implementations jitter like crazy, and/or won't deliver CDDA much quicker than 1x, regardless of what the rated data speed is. http://www.tardis.ed.ac.uk/~psyche/cdda is a good resource for software links and reviews of various models of CD-ROM drives, if CD-DA ripping is of interest. Most good CDR drives also do a good job of CD-DA ripping (Philips CDD-2000, Toshiba CW-7502, from my direct experience), but you probably don't want to wear 'em out doing CD-DA - at least, I know I don't ;-). Personally, I found that tosha worked perfectly even on a Plextor 6x (the only Plextor with flawed firmware, this is pretty well-known). :-) Something like cdparanoia would probably be good for those cheap IDE CD-ROMs (I bought a couple of 16x Hitachi drives cheap - they don't do CD-DA very well at all). Cheers, AS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
