Linux Incompatibility List

Linux Incompatibility List

[David N. Welton]

Hi,

I'm reviving an idea I implemented several years ago, namely the Linux
Incompatibility List.

The idea is simple: most hardware works fine with Linux, and the
situation is generally pretty good, with Linux increasingly showing up
on the corporate radar.

However, there are devices that don't work with Linux, for various
reasons (no specs, too new and no one has written a driver, etc...),
and it's easier to keep track of those devices so that people can
avoid them (or the hero types can write drivers for them).

I have a site up that will serve as the focus of these efforts, but in
order to guage interest/response and ramp up gradually, I'd like to
ask that those interested in participating in the effort send me
information via email.  I'll respond with the wiki's address, so that
they may then have a look around.

I think (correct me if I'm wrong) the information we would want to
collect is:

Product Name:

Manufacturer:

Model Number:

Chipset:

How bad it is (1 to 10, 9 being it almost works and has only minor
bugs):

Reason (no specs, driver still being worked on, ...):

Url for more info:

An email address of yours that we may publish (so that we can contact
you if someone says "no, that works just fine!"):

Notes:

Ideas/comments/suggestions are welcome at this stage.

Thankyou for your time,
-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/

Re: Linux Incompatibility List

[Joseph Pingenot]

>From David N. Welton on Saturday, 21 August, 2004:
>Ideas/comments/suggestions are welcome at this stage.

Sounds interesting; is there a vendor blacklist (i.e. vendors that are
  either hostile toward or simply don't care about Linux and their products
  just won't ever work with Linux?)

-- 
Joseph===============================================trelane@digitasaru.net
      Graduate Student in Physics, Freelance Free Software Developer

Re: Linux Incompatibility List

[Wakko Warner]

> >Ideas/comments/suggestions are welcome at this stage.
> 
> Sounds interesting; is there a vendor blacklist (i.e. vendors that are
>   either hostile toward or simply don't care about Linux and their products
>   just won't ever work with Linux?)

Broadcom's wireless chips come to mind...

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Linux Incompatibility List

[Lee Revell]

On Sat, 2004-08-21 at 16:20, Wakko Warner wrote:
> > >Ideas/comments/suggestions are welcome at this stage.
> > 
> > Sounds interesting; is there a vendor blacklist (i.e. vendors that are
> >   either hostile toward or simply don't care about Linux and their products
> >   just won't ever work with Linux?)
> 
> Broadcom's wireless chips come to mind...

Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
reverse-engineered.

To add insult to injury they have a stupid 20+page 'Nvidia Linux
Advantage' whitepaper on their site that conveniently fails to mention
the above.  They probably spent more money for some marketroid to put
that together than they ever spent on actually supporting Linux.

Lee

Re: Linux Incompatibility List

[Wakko Warner]

> > > >Ideas/comments/suggestions are welcome at this stage.
> > > 
> > > Sounds interesting; is there a vendor blacklist (i.e. vendors that are
> > >   either hostile toward or simply don't care about Linux and their products
> > >   just won't ever work with Linux?)
> > 
> > Broadcom's wireless chips come to mind...
> 
> Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
> reverse-engineered.

True, however, their video cards *DO* work on linux (even though it is
binary-only).  I have a laptop that has the chip.  Does any broadcom
wireless chip work on linux (ndis wrapper or that piece of junk from
linuxant doesn't count)

> To add insult to injury they have a stupid 20+page 'Nvidia Linux
> Advantage' whitepaper on their site that conveniently fails to mention
> the above.  They probably spent more money for some marketroid to put
> that together than they ever spent on actually supporting Linux.

Haven't seen that myself.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Linux Incompatibility List

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Sat, 2004-08-21 16:51:57 -0400, Wakko Warner <wakko@animx.eu.org>
wrote in message <20040821205157.GA9300@animx.eu.org>:
> > Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
> > reverse-engineered.
> 
> True, however, their video cards *DO* work on linux (even though it is
> binary-only).  I have a laptop that has the chip.  Does any broadcom
> wireless chip work on linux (ndis wrapper or that piece of junk from
> linuxant doesn't count)

Right, binary-only drivers and/or GPLed/OSS drivers should be counted
separately. Think about AVM's ISDN cards (very popular over here in
Germany, but the newer products require a CAPI-only binary-only
driver:-(

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux Incompatibility List

[Lee Revell]

On Sat, 2004-08-21 at 17:06, Jan-Benedict Glaw wrote:
> On Sat, 2004-08-21 16:51:57 -0400, Wakko Warner <wakko@animx.eu.org>
> wrote in message <20040821205157.GA9300@animx.eu.org>:
> > > Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
> > > reverse-engineered.
> > 
> > True, however, their video cards *DO* work on linux (even though it is
> > binary-only).  I have a laptop that has the chip.  Does any broadcom
> > wireless chip work on linux (ndis wrapper or that piece of junk from
> > linuxant doesn't count)
> 
> Right, binary-only drivers and/or GPLed/OSS drivers should be counted
> separately. Think about AVM's ISDN cards (very popular over here in
> Germany, but the newer products require a CAPI-only binary-only
> driver:-(
> 

Are there still vendors who release 'open source' drivers, but with
preprocessed, obfuscated source code?  If so then there should be a
category for this.

Lee

Re: Linux Incompatibility List

[Lee Revell]

On Sat, 2004-08-21 at 17:06, Jan-Benedict Glaw wrote:
> On Sat, 2004-08-21 16:51:57 -0400, Wakko Warner <wakko@animx.eu.org>
> wrote in message <20040821205157.GA9300@animx.eu.org>:
> > > Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
> > > reverse-engineered.
> > 
> > True, however, their video cards *DO* work on linux (even though it is
> > binary-only).  I have a laptop that has the chip.  Does any broadcom
> > wireless chip work on linux (ndis wrapper or that piece of junk from
> > linuxant doesn't count)
> 
> Right, binary-only drivers and/or GPLed/OSS drivers should be counted
> separately. Think about AVM's ISDN cards (very popular over here in
> Germany, but the newer products require a CAPI-only binary-only
> driver:-(
> 

Also, it's probably best to focus on new products.  Many vendors, VIA
for example, are now very Linux friendly, but were not always so in the
past, and may not be able to release OSS drivers for older products due
to IP issues.

Lee 

Re: Linux Incompatibility List

[Tonnerre]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Salut,

On Sat, Aug 21, 2004 at 11:06:06PM +0200, Jan-Benedict Glaw wrote:
> Right, binary-only drivers and/or GPLed/OSS drivers should be counted
> separately. Think about AVM's ISDN cards (very popular over here in
> Germany, but the newer products require a CAPI-only binary-only
> driver:-(

Actually I  bought a  Fritz!Card PCI some  days ago in  the Mediamarkt
Basel and  both the mISDN  driver and the  old i4l driver  are working
perfectly well. So what?

				Tonnerre

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux Incompatibility List

[Michael Buesch]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

Quoting Tonnerre <tonnerre@thundrix.ch>:
> Actually I  bought a  Fritz!Card PCI some  days ago in  the Mediamarkt
> Basel and  both the mISDN  driver and the  old i4l driver  are working
> perfectly well. So what?

FritzCard DSL works with binary only driver, only.

-- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux Incompatibility List

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Sun, 2004-08-22 16:30:09 +0200, Tonnerre <tonnerre@thundrix.ch>
wrote in message <20040822143009.GD19768@thundrix.ch>:
> On Sat, Aug 21, 2004 at 11:06:06PM +0200, Jan-Benedict Glaw wrote:
> > Right, binary-only drivers and/or GPLed/OSS drivers should be counted
> > separately. Think about AVM's ISDN cards (very popular over here in
> > Germany, but the newer products require a CAPI-only binary-only
> > driver:-(
> 
> Actually I  bought a  Fritz!Card PCI some  days ago in  the Mediamarkt
> Basel and  both the mISDN  driver and the  old i4l driver  are working
> perfectly well. So what?

So you bought one of the old version. The new cards are "Version 2.0"
IIRC.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux Incompatibility List

[Michael Buesch]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

Quoting Jan-Benedict Glaw <jbglaw@lug-owl.de>:
> > Actually I  bought a  Fritz!Card PCI some  days ago in  the Mediamarkt
> > Basel and  both the mISDN  driver and the  old i4l driver  are working
> > perfectly well. So what?
> 
> So you bought one of the old version. The new cards are "Version 2.0"
> IIRC.

Version 2.0 works perfectly well with the open driver.
The v2 driver is a separate driver. But it's in the tree and working
for ages.

-- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux Incompatibility List

[Francois Romieu]

Wakko Warner <wakko@animx.eu.org> :
[...]
> True, however, their video cards *DO* work on linux (even though it is
> binary-only).  I have a laptop that has the chip.  Does any broadcom

Mantra: linux is not x86 only.

Btw have you considered discussion with the people behind
http://www.linuxhardware.net/ ?

--
Ueimor

Re: Linux Incompatibility List

[Wakko Warner]

> > True, however, their video cards *DO* work on linux (even though it is
> > binary-only).  I have a laptop that has the chip.  Does any broadcom
> 
> Mantra: linux is not x86 only.

I forgot about that.  There's an alpha box sitting next to me =)

> Btw have you considered discussion with the people behind
> http://www.linuxhardware.net/ ?

Not sure if I've been there before.  I may have.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Linux Incompatibility List

[Andrew Miklas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On August 21, 2004 04:51 pm, Wakko Warner wrote:
<snip>
> Does any broadcom
> wireless chip work on linux (ndis wrapper or that piece of junk from
> linuxant doesn't count)

Yeah, their wireless chips work fine on Linux if you are running just about 
any wireless access point / router that makes use of Broadcom's hardware.  

That probably seems like a pointless nitpick, but I think that makes their 
non-support of Linux on general-purpose hardware even worse.  They've already 
written wireless drivers for Linux, but simply refuse to work with anyone to 
get their hardware running under Linux for other architectures.  They even 
refuse to simply recompile their driver for i386 and release it binary-only.  
For that matter, they won't even respond to e-mail on the subject.  (The most 
I've ever got from them was a few engineers responding 'off the record'.)

Even more annoying is the way their Linux/MIPSel binaries are tied to a 
particular kernel version.  (They've got the inlines from skbuff.h scattered 
all over their module --- at least they did in the driver included with the 
Linksys WAP54G v. 1.08 which was the one I carefully looked at.)  This 
creates a serious problem for anyone who wants to get their wireless 
routers / access points to run a different version of the kernel.

They seem to be very selective about when they acknowledge Linux's existence.  
IMHO, this makes them even worse than a company that has decided to simply 
ignore Linux all together.



- -- Andrew
-----BEGIN PGP SIGNATURE-----
Comment: Key ID: EC3F6CCD (www.keyserver.net)

iD8DBQFBJ+CNTHKGaOw/bM0RAoGJAJoCJOZTuNayN2jCmzCfSbXAbUhkmgCfdk5G
vLETYsG6DBPFZ5jBeq4MGbM=
=r+T+
-----END PGP SIGNATURE-----

Re: Linux Incompatibility List

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Sat, 2004-08-21 at 19:53 -0400, Andrew Miklas wrote:
> They seem to be very selective about when they acknowledge Linux's existence.  
> IMHO, this makes them even worse than a company that has decided to simply 
> ignore Linux all together.

http://www.scaramanga.co.uk/stuff/bcm94306/

There is at least 1 effort underway to reverse engineer it, although I
don't have much time to work on it. IMO It would be good if such
companies were consistently shown that we certainly don't need them to
write drivers for us and even if they go out of their way, there isn't
much they can do to stop us from writing them ourselves.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux Incompatibility List

[Andrew Miklas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On August 22, 2004 11:54 pm, Gianni Tedesco wrote:
<snip>
> There is at least 1 effort underway to reverse engineer it, although I
> don't have much time to work on it. IMO It would be good if such
> companies were consistently shown that we certainly don't need them to
> write drivers for us and even if they go out of their way, there isn't
> much they can do to stop us from writing them ourselves.

I've been working with a few people to reverse engineer the drivers included 
with the WAP54G 1.08.  We're about 50% done translating them back into C.  
Once we're done, we plan to study the driver in order to write our own from 
scratch, or ask someone else to cleanroom it.

However, it's likely that by the time we're done (if ever), the hardware will 
be supplanted by something else.  We've learnt the hard way that reverse 
engineering a 420K binary, and completing in a reasonable time isn't as easy 
as it sounds.  :)  This is especially true when you can't simply make 
everything public (out of copyright concerns) and do the project in a real 
open source way.  


- -- Andrew
-----BEGIN PGP SIGNATURE-----
Comment: Key ID: EC3F6CCD (www.keyserver.net)

iD8DBQFBLCqyTHKGaOw/bM0RAhsjAKCH6Ftt9gp5raK2PfPEfDoKb8bxPwCeNY7y
ilSEs+jG1514W6zz/WGBNQg=
=QrAv
-----END PGP SIGNATURE-----

Re: Linux Incompatibility List

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On Wed, 2004-08-25 at 01:59 -0400, Andrew Miklas wrote:
> I've been working with a few people to reverse engineer the drivers included 
> with the WAP54G 1.08.  We're about 50% done translating them back into C.  
> Once we're done, we plan to study the driver in order to write our own from 
> scratch, or ask someone else to cleanroom it.
> 
> However, it's likely that by the time we're done (if ever), the hardware will 
> be supplanted by something else.  We've learnt the hard way that reverse 
> engineering a 420K binary, and completing in a reasonable time isn't as easy 
> as it sounds.  :)  This is especially true when you can't simply make 
> everything public (out of copyright concerns) and do the project in a real 
> open source way.  

I agreee, reverse engineering machine code is not trivial, especially
with the tools currently available. However I don't think that the
difficulty is intrinsic. It is possible (though obviously not simple) to
wite software that is able to infer a great deal from machine code
automatically and produce pretty good decompilations.

Also I think that the pciproxy[0] technique currently offers a simpler
solution. Analyzing the data produced is more akin to reverse
engineering a network protocol than machine code. Reverse engineering
protocols is much less 'copyright sensitive' than decompiling machine
code and, I think, more easily shared.

Anyway, perhaps once I've had some time to make a little more progress
we would be able to compare some notes?

[0]. I should probably explain the technique. It basically involves
running supported operating systems under a PC emulator, and trapping
and logging i/o on the PCI bus.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux Incompatibility List

[Andrew Miklas]

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

Hi,

On August 25, 2004 03:21 am, Gianni Tedesco wrote:
<snip>
> Also I think that the pciproxy[0] technique currently offers a simpler
> solution. Analyzing the data produced is more akin to reverse
> engineering a network protocol than machine code. Reverse engineering
> protocols is much less 'copyright sensitive' than decompiling machine
> code and, I think, more easily shared.

(Sorry for the long delay...)

Yeah, we tried that at first too (actually, we were using Frank Cornelis'  
patches to Bochs).  The problem with dumping all the PCI activity (even while 
the interface isn't sending/receiving) is that there is a huge amount of data 
to sift through.  Even capturing for just a for a few seconds generates 
megabytes of data.  You also have to deal with various events (like the 
watchdog timer) going off at random times and getting mixed in with the 
send/receive data.  We also found DMA a little tricky too (ie. you need to 
dump out any data that the chip will bus-master to itself to see how it is 
structured).

Also, we figured it would cause problems for supporting the whole range of 
devices that can be handled by the wl.o drivers.  For example, from looking 
at the module, we can see that the driver will have somewhat different 
behaviour according to exactly what MAC and radio chips are present, the 
interface being used (ie. PCI, cardbus, etc.), the vendor, model number, and 
revision of the board itself, the contents of the ROM, etc.  We decided that 
there was simply too many combinations to make the data capture approach 
useful over the entire range of Broadcom hardware, unless you repeat the 
process on every variation.


> Anyway, perhaps once I've had some time to make a little more progress
> we would be able to compare some notes?

Sure, let me know when you're ready.


-- Andrew

[-- Attachment #2: Type: application/pgp-signature, Size: 201 bytes --]

Re: Linux Incompatibility List

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

On Sat, 2004-08-28 at 21:42 -0400, Andrew Miklas wrote:
> (Sorry for the long delay...)

Thats OK.

> Yeah, we tried that at first too (actually, we were using Frank Cornelis'  
> patches to Bochs).  The problem with dumping all the PCI activity (even while 
> the interface isn't sending/receiving) is that there is a huge amount of data 
> to sift through.  Even capturing for just a for a few seconds generates 
> megabytes of data.  You also have to deal with various events (like the 
> watchdog timer) going off at random times and getting mixed in with the 
> send/receive data.  We also found DMA a little tricky too (ie. you need to 
> dump out any data that the chip will bus-master to itself to see how it is 
> structured).

OK, exactly which drivers were you using to do this? When I had the
interface brought up in win2k-server with the bcmwl5.sys driver I was
seeing every few hundred milliseconds a batch of say 12 2-byte reads on
the register space to check status...

> Also, we figured it would cause problems for supporting the whole range of 
> devices that can be handled by the wl.o drivers.  For example, from looking 
> at the module, we can see that the driver will have somewhat different 
> behaviour according to exactly what MAC and radio chips are present, the 
> interface being used (ie. PCI, cardbus, etc.), the vendor, model number, and 
> revision of the board itself, the contents of the ROM, etc.  We decided that 
> there was simply too many combinations to make the data capture approach 
> useful over the entire range of Broadcom hardware, unless you repeat the 
> process on every variation.

Hrm, you're sure those variations aren't trivial? Although theres lots
of checks, I would have thought they would just be stuff like "card A
supports X, Y and Z features"?

The approach that makes the most sense to me is get 1 card working to
the point where it sends/receives packets, then look at the binaries to
see what the variations are, and how they apply to what cards and just
go fill in the blanks...

> > Anyway, perhaps once I've had some time to make a little more progress
> > we would be able to compare some notes?
> 
> Sure, let me know when you're ready.

I just need to improve logging support in my pciproxy patch and setup a
2nd machine with a working wireless card, then I can start in earnest.

Also, you mention DMA and sending/receiving packets, exactly how much
progress have you made so far?

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux Incompatibility List

[Andrew Miklas]

[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]

Hi,


On August 28, 2004 11:21 pm, Gianni Tedesco wrote:
<snip>
> OK, exactly which drivers were you using to do this? When I had the
> interface brought up in win2k-server with the bcmwl5.sys driver I was
> seeing every few hundred milliseconds a batch of say 12 2-byte reads on
> the register space to check status...

I was never able to get it going myself (If I remember correctly, there was 
some issue with how the interrupts were being routed on my notebook.  We were 
doing some strange stuff to forward interrupts from the host kernel into 
Bochs that didn't work on all configurations.)

However, Frank Cornelis was using the Windows 98 drivers running under Win98 
on pcidev+Bochs.  Kendall Blake was using the Windows XP drivers and a 
modified ndiswrapper running under Linux also on pcidev+Bochs.  Kendall told 
me that he generated about 400 megs of logs just looking at the card 
initialization.  I think it was at this point I decided that decompiling the 
thing would be easier.  :)

Anyway, you could try asking Frank and Kendall for some of the data they 
gathered.

kendallb () eden rutgers edu
fcorneli () pandora be


<snip>
>
> Hrm, you're sure those variations aren't trivial? Although theres lots
> of checks, I would have thought they would just be stuff like "card A
> supports X, Y and Z features"?

The differences between radio chips (ex. a vs. g) aren't going to be trivial.  
That is to say, entirely different code paths are executed in the wlc_phy.o 
component.  The variations caused by different board configurations don't 
appear to be too big (at least from the code I've looked at).  Some of the 
variations (probably bug fixes) caused by different revisions of the chips 
are also a little large.  But, I think it will be pretty difficult to 
determine how the differences in the dumps relate to differences in the 
hardware configuration.


>
> The approach that makes the most sense to me is get 1 card working to
> the point where it sends/receives packets, then look at the binaries to
> see what the variations are, and how they apply to what cards and just
> go fill in the blanks...

The problem is that all Broadcom's wireless hardware is supported by one big 
driver.  If you wanted to be able to see the differences between what code is 
executed against each device, you'd pretty much have to decompile the whole 
thing, or at least do some serious debugger work.  Assuming you don't want to 
do that, it seems you're left with doing the capture analysis on every 
variation, which doesn't seem practical.


<snip>
> Also, you mention DMA and sending/receiving packets, exactly how much
> progress have you made so far?

I'm pretty sure that they were able to get packets to go back and forth.  But, 
the last I heard from anyone using the capture method with pcidev and Bochs 
was about six months ago.


-- Andrew

[-- Attachment #2: Type: application/pgp-signature, Size: 201 bytes --]

Re: Linux Incompatibility List

[Jonathan Bastien-Filiatrault]

Lee Revell wrote:

>On Sat, 2004-08-21 at 16:20, Wakko Warner wrote:
>  
>
>>>>Ideas/comments/suggestions are welcome at this stage.
>>>>        
>>>>
>>>Sounds interesting; is there a vendor blacklist (i.e. vendors that are
>>>  either hostile toward or simply don't care about Linux and their products
>>>  just won't ever work with Linux?)
>>>      
>>>
>>Broadcom's wireless chips come to mind...
>>    
>>
>
>Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
>reverse-engineered.
>
>To add insult to injury they have a stupid 20+page 'Nvidia Linux
>Advantage' whitepaper on their site that conveniently fails to mention
>the above.  They probably spent more money for some marketroid to put
>that together than they ever spent on actually supporting Linux.
>  
>
Vendors should understand that ACTUALLY supporting linux means adopting 
the free software philosophy. In many cases, vendors think that they 
should be the only one to be able to write drivers, since 99% of desktop 
users dont care about their software freedom. Vendors should not try to 
obscure the workings of their devices, they should show the world how 
they are innovating in hardware design by releasing specs on a 
freely-redistributable basis. This would greatly improve competiveness 
and innovation in the domain of hardware design. Give me a binary driver 
and i will  buy from you once, give me the specs and i'll appreciate the 
effort you put in designing the device.

Re: Linux Incompatibility List

[James Courtier-Dutton]

Jonathan Bastien-Filiatrault wrote:
>>
> Vendors should understand that ACTUALLY supporting linux means adopting 
> the free software philosophy. In many cases, vendors think that they 
> should be the only one to be able to write drivers, since 99% of desktop 
> users dont care about their software freedom. Vendors should not try to 
> obscure the workings of their devices, they should show the world how 
> they are innovating in hardware design by releasing specs on a 
> freely-redistributable basis. This would greatly improve competiveness 
> and innovation in the domain of hardware design. Give me a binary driver 
> and i will  buy from you once, give me the specs and i'll appreciate the 
> effort you put in designing the device.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

I remember a computer from pre ibm-pc days. It came with a manual that 
included a detailed circuit diagram, so the user could make any repairs 
they wished. It also gave details regarding CPU instruction set, and 
memory layout, so that anyone could write any OS they liked for it.

If we do create a nice long list, we should also include Linux 
compatible hardware as well.
E.g. Latest XYZ laptop, it would list all the chips in the laptop, 
together with what level of support linux has for each one.
The problem comes with actually identifying the parts.
For example, Creative have lots of different sound cards, all called the 
  SB Live, but they all have very different chips in them, with some 
supported by linux, and some not. Don't you just love those Marketing 
people. :-(
We can use PCI IDs and PCI subsystem IDs, to identify Motherboards, and 
PCI cards. We might also have to identify revision numbers.
We can use USB IDs to identify USB devices.

As an aid to this, I think we should create a script, that will gather 
the IDs in a consistent way, so that a user just runs the script, adds a 
comment, and submits it to the database.

Re: Linux Incompatibility List

[Jonathan Bastien-Filiatrault]

James Courtier-Dutton wrote:

> Jonathan Bastien-Filiatrault wrote:
>
>>>
>> Vendors should understand that ACTUALLY supporting linux means 
>> adopting the free software philosophy. In many cases, vendors think 
>> that they should be the only one to be able to write drivers, since 
>> 99% of desktop users dont care about their software freedom. Vendors 
>> should not try to obscure the workings of their devices, they should 
>> show the world how they are innovating in hardware design by 
>> releasing specs on a freely-redistributable basis. This would greatly 
>> improve competiveness and innovation in the domain of hardware 
>> design. Give me a binary driver and i will  buy from you once, give 
>> me the specs and i'll appreciate the effort you put in designing the 
>> device.
>> -
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
>
> I remember a computer from pre ibm-pc days. It came with a manual that 
> included a detailed circuit diagram, so the user could make any 
> repairs they wished. It also gave details regarding CPU instruction 
> set, and memory layout, so that anyone could write any OS they liked 
> for it.

My dad had a thing like that(quick reference card) for an old motorola 
6800(not 68000) processor. It only had 2 8-bit general purpose registers 
if I remember correctly. Doesn't even begin to compare with modern ppc 
processors.

>  
> If we do create a nice long list, we should also include Linux 
> compatible hardware as well.
> E.g. Latest XYZ laptop, it would list all the chips in the laptop, 
> together with what level of support linux has for each one.
> The problem comes with actually identifying the parts.
> For example, Creative have lots of different sound cards, all called 
> the  SB Live, but they all have very different chips in them, with 
> some supported by linux, and some not. Don't you just love those 
> Marketing people. :-(
> We can use PCI IDs and PCI subsystem IDs, to identify Motherboards, 
> and PCI cards. We might also have to identify revision numbers.
> We can use USB IDs to identify USB devices.

Good idea, we should have something like two lists one for "chips" and 
one for "containers of chips" aka whole systems. That way it could be 
cross-referenced in a database-like way with a nice gtk frontend. The 
project probably ressemble the pci-ids project. That would pave the way 
for a free(as in speech) hardware purchasing guide.

Re: Linux Incompatibility List

[Kyle Moffett]

On Aug 22, 2004, at 02:36, Jonathan Bastien-Filiatrault wrote:
> My dad had a thing like that(quick reference card) for an old motorola 
> 6800(not 68000) processor. It only had 2 8-bit general purpose 
> registers if I remember correctly. Doesn't even begin to compare with 
> modern ppc processors.

Hey! I built a primitive computer from one of those in a microprocessor 
class a year ago.  2 8-bit registers, 8-bit data-bus and 16-bit address 
bus.  There were two interrupt pins, IRQ and NMI, and a simple 
condition code register.  The CPU clock is the same as the bus clock.  
What fun!!!

> Good idea, we should have something like two lists one for "chips" and 
> one for "containers of chips" aka whole systems. That way it could be 
> cross-referenced in a database-like way with a nice gtk frontend. The 
> project probably ressemble the pci-ids project. That would pave the 
> way for a free(as in speech) hardware purchasing guide.

A well designed guide could go a long way toward convincing companies 
to release specs.  When a well known hardware website has user 
testimonials that the drivers suck, the tech support are unhelpful, and 
the company just doesn't get it, said company will probably tend to 
listen.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: Linux Incompatibility List

[Lee Revell]

On Sun, 2004-08-22 at 00:15, Kyle Moffett wrote:
> > Good idea, we should have something like two lists one for "chips" and 
> > one for "containers of chips" aka whole systems. That way it could be 
> > cross-referenced in a database-like way with a nice gtk frontend. The 
> > project probably ressemble the pci-ids project. That would pave the 
> > way for a free(as in speech) hardware purchasing guide.
> 
> A well designed guide could go a long way toward convincing companies 
> to release specs.  When a well known hardware website has user 
> testimonials that the drivers suck, the tech support are unhelpful, and 
> the company just doesn't get it, said company will probably tend to 
> listen.
> 

Takashi Iwai's 'Writing an ALSA driver' (google for it) is IMHO the
exemplar in this area.  It is written at *exactly* the right level.
Several major vendors have come on alsa-devel and posted to the effect
that they followed this guide and have their driver 99% working, they
just need help with this or that, someone answers a question or two, and
bang, one more Linux-supported device.  There should be a document of
this quality covering every major category of driver.

Lee

Re: Linux Incompatibility List

[Geert Uytterhoeven]

On Sun, 22 Aug 2004, Kyle Moffett wrote:
> A well designed guide could go a long way toward convincing companies
> to release specs.  When a well known hardware website has user
> testimonials that the drivers suck, the tech support are unhelpful, and
> the company just doesn't get it, said company will probably tend to
> listen.

Or use [ your favorite new law of the day ] to bring the site and/or the
comments down?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Linux Incompatibility List

[R. J. Wysocki]

On Sunday 22 of August 2004 10:05, Geert Uytterhoeven wrote:
> On Sun, 22 Aug 2004, Kyle Moffett wrote:
> > A well designed guide could go a long way toward convincing companies
> > to release specs.  When a well known hardware website has user
> > testimonials that the drivers suck, the tech support are unhelpful, and
> > the company just doesn't get it, said company will probably tend to
> > listen.
>
> Or use [ your favorite new law of the day ] to bring the site and/or the
> comments down?

If it tries to, we'll only need to find a journalist searching for a story.  
;-)

Greetings,
-- 
Rafael J. Wysocki
----------------------------
For a successful technology, reality must take precedence over public 
relations, for nature cannot be fooled.
					-- Richard P. Feynman

Re: Linux Incompatibility List

[Gene Heskett]

On Sunday 22 August 2004 08:07, R. J. Wysocki wrote:
>On Sunday 22 of August 2004 10:05, Geert Uytterhoeven wrote:
>> On Sun, 22 Aug 2004, Kyle Moffett wrote:
>> > A well designed guide could go a long way toward convincing
>> > companies to release specs.  When a well known hardware website
>> > has user testimonials that the drivers suck, the tech support
>> > are unhelpful, and the company just doesn't get it, said company
>> > will probably tend to listen.
>>
>> Or use [ your favorite new law of the day ] to bring the site
>> and/or the comments down?
>
>If it tries to, we'll only need to find a journalist searching for a
> story. ;-)
>
>Greetings,

How about mentioning it on /.?  Thats usually good for a takedown if 
they don't have big iron and pipes to suit. :-)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.24% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: Linux Incompatibility List

[Hamie]

Kyle Moffett wrote:

> On Aug 22, 2004, at 02:36, Jonathan Bastien-Filiatrault wrote:
>
>> My dad had a thing like that(quick reference card) for an old 
>> motorola 6800(not 68000) processor. It only had 2 8-bit general 
>> purpose registers if I remember correctly. Doesn't even begin to 
>> compare with modern ppc processors.
>
>
> Hey! I built a primitive computer from one of those in a 
> microprocessor class a year ago.  2 8-bit registers, 8-bit data-bus 
> and 16-bit address bus.  There were two interrupt pins, IRQ and NMI, 
> and a simple condition code register.  The CPU clock is the same as 
> the bus clock.  What fun!!!
>

Here's where I feel my age... 6502 with ONE (That's 1) general purpose 
register (Called the accumulator)... Plus a couple of others used mainly 
for offsets (X & Y if I remember correctly)... No 16-bit maths... All 
8-bit. (As were the registers). Boy the 6809 was easy to program after 
that sucker...

The 6809 (basically an extension of the original 6800)  had 2x 8-bit 
registers IIRC, that you could actually treat as a single 16-bit 
register as well (i.e. multiply one 8bit by the seocnd & read the result 
from the '16-bit' register... The assember language on the 6800 series 
was way better than the 6502 (And the 6510).

but I digress... Even IBM were good with open source. I think I still 
have an IBM PC tech reference around here with the complete source code 
listing (In x86 assembler) of the original IBM PC Bios. Now that made 
for innovation... Open hardware & software. Heck most of these companies 
need a good reminder that if they hadn't had a leg up fro Open computing 
in the early 80's they wouldn't be here today.

H

Re: Linux Incompatibility List

[Tonnerre]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Salut,

On Sun, Aug 22, 2004 at 01:29:48AM -0400, Jonathan Bastien-Filiatrault wrote:
> Vendors should understand that ACTUALLY supporting linux means adopting 
> the free software philosophy.

Actually look  at what  happened when the  probing part of  the NVidia
driver was published: people looked at it and fixed bugs.

Opensourcing a driver can actually be a benefit for the company, since
they don't  need to pay  some maintainer for  it then plus  they won't
need  to put  up  with problems  after  kernel changes  and stuff  and
neither with bugs in the code.

The  problem is  that people  still  think that  there is  intelectual
property and that it can be stolen. (The famous blackbird case (Yes, I
said the B word!)) But look at UNESCO: maybe one day the world will be
different.

				Tonnerre
			(Part-time UN coworker)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux Incompatibility List

[Alan Cox]

On Sad, 2004-08-21 at 21:31, Lee Revell wrote:
> Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
> reverse-engineered.

The X 2D driver isnt too easy to read (although with the rivatv notes
its quite easy). That was written by Nvidia employees and provided by
Nvidia.

Alan

Re: Linux Incompatibility List

[Dave Jones]

On Sun, Aug 22, 2004 at 12:10:15PM +0100, Alan Cox wrote:
 > On Sad, 2004-08-21 at 21:31, Lee Revell wrote:
 > > Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
 > > reverse-engineered.
 > 
 > The X 2D driver isnt too easy to read (although with the rivatv notes
 > its quite easy). That was written by Nvidia employees and provided by
 > Nvidia.

As was the nForce AGP GART driver. Some folks in NVidia are trying
to do the right thing wherever possible.

		Dave

Re: Linux Incompatibility List

[Eric W. Biederman]

Dave Jones <davej@redhat.com> writes:

> On Sun, Aug 22, 2004 at 12:10:15PM +0100, Alan Cox wrote:
>  > On Sad, 2004-08-21 at 21:31, Lee Revell wrote:
>  > > Nvidia.  AFAIK all nvidia Linux drivers are either binary-only or
>  > > reverse-engineered.
>  > 
>  > The X 2D driver isnt too easy to read (although with the rivatv notes
>  > its quite easy). That was written by Nvidia employees and provided by
>  > Nvidia.
> 
> As was the nForce AGP GART driver. Some folks in NVidia are trying
> to do the right thing wherever possible.

This will be an interesting space to watch I guess.

Tyan is working on an LinuxBIOS to Nvidia's most recent
Opteron chipset as well.    And Nvidia seems to be helping.

Eric

Re: Linux Incompatibility List

[David N. Welton]

Wakko Warner <wakko@animx.eu.org> writes:

> > >Ideas/comments/suggestions are welcome at this stage.
> > 
> > Sounds interesting; is there a vendor blacklist (i.e. vendors that are
> >   either hostile toward or simply don't care about Linux and their products
> >   just won't ever work with Linux?)
> 
> Broadcom's wireless chips come to mind...

Sounds good.  I wouldn't know one if it bit me on the leg, though, can
you point to list archives, a web site, or reassure me that if I
google for it I will get the right information?  I'd like models or a
range of models if possible, and why they don't work, and any notes or
additional information about the situation.

Thanks!
-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/

Re: Linux Incompatibility List

[Wakko Warner]

> > > >Ideas/comments/suggestions are welcome at this stage.
> > > 
> > > Sounds interesting; is there a vendor blacklist (i.e. vendors that are
> > >   either hostile toward or simply don't care about Linux and their products
> > >   just won't ever work with Linux?)
> > 
> > Broadcom's wireless chips come to mind...
> 
> Sounds good.  I wouldn't know one if it bit me on the leg, though, can
> you point to list archives, a web site, or reassure me that if I
> google for it I will get the right information?  I'd like models or a
> range of models if possible, and why they don't work, and any notes or
> additional information about the situation.

The linksys G cards (pci/cardbus) both use broadcom chips.  Not sure the
exact model numbers.  I have 2 at work that are broadcom.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Linux Incompatibility List

[Rutger Nijlunsing]

On Sat, Aug 21, 2004 at 06:03:59PM -0400, Wakko Warner wrote:
> > > > >Ideas/comments/suggestions are welcome at this stage.
> > > > 
> > > > Sounds interesting; is there a vendor blacklist (i.e. vendors that are
> > > >   either hostile toward or simply don't care about Linux and their products
> > > >   just won't ever work with Linux?)
> > > 
> > > Broadcom's wireless chips come to mind...
> > 
> > Sounds good.  I wouldn't know one if it bit me on the leg, though, can
> > you point to list archives, a web site, or reassure me that if I
> > google for it I will get the right information?  I'd like models or a
> > range of models if possible, and why they don't work, and any notes or
> > additional information about the situation.
> 
> The linksys G cards (pci/cardbus) both use broadcom chips.  Not sure the
> exact model numbers.  I have 2 at work that are broadcom.

Most routers with 4 ethernet ports for internal network, 1 ethernet
port for external network and a wireless output which have a lot of
functionality run Linux with a closed-source wireless driver:

Linksys WRT54g, ASUS WL-500g/b, and probably more...

-- 
Rutger Nijlunsing ---------------------------- rutger ed tux tmfweb nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

Re: Linux Incompatibility List

[David N. Welton]

Joseph Pingenot <trelane@digitasaru.net> writes:

> >From David N. Welton on Saturday, 21 August, 2004:
> >Ideas/comments/suggestions are welcome at this stage.

> Sounds interesting; is there a vendor blacklist (i.e. vendors that
> are either hostile toward or simply don't care about Linux and their
> products just won't ever work with Linux?)

That's part of the idea, but I'd rather stick to "just the facts
ma'm".  With enough entries, it will be evident who to avoid, so send
lots of them to get things rolling!

Thanks,
-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/

Re: Linux Incompatibility List

[Alan Cox]

On Sad, 2004-08-21 at 20:41, David N. Welton wrote:

I think the "compatibility list" side is the more important. Trying to
punish non helpful products/vendors isn't as productive as helping stuff
that is Linux friendly.

> Product Name:
> 
> Manufacturer:
> 
> Model Number:
> 
> Chipset:

At what level is "Product" - do you need a category. How do you want
to classify devices. I think this matters because you want eventually
to be able to deal with things like tools that let users rate their
setup functionality and submit it automatically.
> 
> How bad it is (1 to 10, 9 being it almost works and has only minor
> bugs):
> 
> Reason (no specs, driver still being worked on, ...):
> 
> Url for more info:
> 
> An email address of yours that we may publish (so that we can contact
> you if someone says "no, that works just fine!"):

Wikipedia has a discussion page tagged to each article/entry. This works
extremely well because it provides a public forum for discussion of what
does/doesn't work, why and when.

Could you add "Kernel.org bugzilla #" for not working ones, both to help
people track them and to encourage submissions ?

Alan

Re: Linux Incompatibility List

[Joseph Pingenot]

>From Alan Cox on Sunday, 22 August, 2004:
>On Sad, 2004-08-21 at 20:41, David N. Welton wrote:
>I think the "compatibility list" side is the more important. Trying to
>punish non helpful products/vendors isn't as productive as helping stuff
>that is Linux friendly.

Definitely.  It's great to know that Linux works with a device, since
  I know that I can buy it and actually *use* it.  Double points if
  the *device* works with *linux*!
That said, there are lots of devices out there that aren't listed in the
  compatibility list.  I'd be nice to know if they *don't* work, since I
  won't feel tempted (if the price is right) to take it home and try it
  out.  Although, as another point, it'd be nice to bring all of the
  various device compatibility lists together in one place, esp. for the
  HAL/D-BUS/Utopia system, so that they could potentially query the list
  over the net.  Bonus points for a downloadable version for the distros!
Also, a known-helpful vendor list would be great, as I would be much more
  inclined to buy stuff from vendors who support Linux (as opposed to
  Linux supporting them).  It's important to me, and I like to put my
  money where my mouth is.  :)
In short, we should definitely work on maintaining a big device and vendor
  compatibility list ([butter]flies, honey, vinegar), but a known-bad/hostile
  list is also a nice thing to have, so that we can know to take our
  dollars elsewhere.

-Joseph

-- 
Joseph===============================================trelane@digitasaru.net
      Graduate Student in Physics, Freelance Free Software Developer

Re: Linux Incompatibility List

[David N. Welton]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Sad, 2004-08-21 at 20:41, David N. Welton wrote:

> I think the "compatibility list" side is the more important. Trying
> to punish non helpful products/vendors isn't as productive as
> helping stuff that is Linux friendly.

A "compatibility list" is going to be pretty big, and hard to keep up
to date.  My thinking is that keeping track of a few notable things
that don't work is easier than running after all the stuff that does.

Of course, if automation can be brought to bear, that might make
either one much easier, but I'm dubious, because "it doesn't work" is
a vague concept, and really ought to be researched some.

A third concept "look, these guys support Linux really well!" (not
just "ok, it works") might also be easy to do.

By the way, the concept is not really about punishing vendors, and I
don't want it to come off looking like that.  It's about "this piece
of hardware does not work with Linux".  Who knows, maybe the fault is
with the kernel maintainers:-)  It might be nice if that gave some
incentive to the manufacturers to help bring the driver up to speed,
though.

> At what level is "Product" - do you need a category. How do you want
> to classify devices. I think this matters because you want
> eventually to be able to deal with things like tools that let users
> rate their setup functionality and submit it automatically.

I'd be worried about people who are just irritated that their system
didn't work out of the box hitting a button to submit this
information.

I suppose some sort of vote system could be put in place so that the 1
guy who didn't get the hardware to work gets outvoted by the 10 who
did, but there is more incentive to hit the button when you are
irritated than when everything 'just worked'.

> > How bad it is (1 to 10, 9 being it almost works and has only minor
> > bugs):

> > Reason (no specs, driver still being worked on, ...):

> > Url for more info:

> > An email address of yours that we may publish (so that we can contact
> > you if someone says "no, that works just fine!"):

> Wikipedia has a discussion page tagged to each article/entry. This
> works extremely well because it provides a public forum for
> discussion of what does/doesn't work, why and when.

It's a wiki, so for now I think placing comments on the bottom of the
page would be sensible.  We'll see if and how it grows.

> Could you add "Kernel.org bugzilla #" for not working ones, both to
> help people track them and to encourage submissions ?

Excellent idea.

Thanks for your thoughts,
-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/

Re: Linux Incompatibility List

[Alan Cox]

On Sul, 2004-08-22 at 21:48, David N. Welton wrote:
> A "compatibility list" is going to be pretty big, and hard to keep up
> to date.  My thinking is that keeping track of a few notable things
> that don't work is easier than running after all the stuff that does.

Its already been kicked around on the Fedora list to actually build such
a database automatically. I've seen similar Debian proposals a long time
ago. That means some time post install you'd let the user
fire up a system report tool which would ask things like

	"Does sound work"

and then fire off PCI id/rating info to a central site. That would help
deal with the data collection much as the Debian folks collect package
popularity statistics.

> I suppose some sort of vote system could be put in place so that the 1
> guy who didn't get the hardware to work gets outvoted by the 10 who
> did, but there is more incentive to hit the button when you are
> irritated than when everything 'just worked'.

If you get enough data then the deviation tells you how varied and how
reliable the opinions are likely to be, all this implies databases not
WIki however


Alan

Re: Linux Incompatibility List

[cliff white]

On Sun, 22 Aug 2004 21:45:27 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Sul, 2004-08-22 at 21:48, David N. Welton wrote:
> > A "compatibility list" is going to be pretty big, and hard to keep up
> > to date.  My thinking is that keeping track of a few notable things
> > that don't work is easier than running after all the stuff that does.
> 
> Its already been kicked around on the Fedora list to actually build such
> a database automatically. I've seen similar Debian proposals a long time
> ago. That means some time post install you'd let the user
> fire up a system report tool which would ask things like
> 
> 	"Does sound work"
> 
> and then fire off PCI id/rating info to a central site. That would help
> deal with the data collection much as the Debian folks collect package
> popularity statistics.
> 
> > I suppose some sort of vote system could be put in place so that the 1
> > guy who didn't get the hardware to work gets outvoted by the 10 who
> > did, but there is more incentive to hit the button when you are
> > irritated than when everything 'just worked'.
> 
> If you get enough data then the deviation tells you how varied and how
> reliable the opinions are likely to be, all this implies databases not
> WIki however
> 
This sounds very interesting indeed. We (OSDL) have been talking about how to
extend our testing into the ISV space, and how to supply useful data. This 
type of post-install, post-test 'i look like this, and this runs' data capture
would be real useful, especially if we could capture software info also.
Who else was interested in this?
cliffw

> 
> Alan
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
The church is near, but the road is icy.
The bar is far, but i will walk carefully. - Russian proverb

Re: Linux Incompatibility List

[David N. Welton]

Michael Buesch <mbuesch@freenet.de> writes:

> What about some Wiki based database?

That's what it is, more or less.  I'm just putting the finishing
touches on the wiki software, and I wanted to ask for a few
entries to work with, and people interested in playing with the wiki
before publicizing it.

Oh, just so it's clear, by the way, the contents of the wiki will be
under a free license.

-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/

Re: Linux Incompatibility List

[David N. Welton]

[BTW, please CC replies to me. Thanks! ]

As far as binary only drivers and things of that ilk, I intend to list
them on the site, and describe the situation as accurately as
possible: "this does work, on x86, but only with one guaranteed kernel
version, etc...".  I would rate it around a 5 out of 10.  With that in
mind, specific model numbers/chipsets/whatever else is available for
nVidia and broadcom equipment is welcome.  I will put those on the
wiki myself (still got some kinks).

I don't want to beat up on companies, or at least that's not the
central idea.  I want to provide a place for people to check quickly
if they're thinking about buying something, or if they've just bought
it, so they can see what the potential problems are.

Thankyou,
-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/

Re: Linux Incompatibility List

[Helge Hafting]

David N. Welton wrote:

>Hi,
>
>I'm reviving an idea I implemented several years ago, namely the Linux
>Incompatibility List.
>
>The idea is simple: most hardware works fine with Linux, and the
>situation is generally pretty good, with Linux increasingly showing up
>on the corporate radar.
>
>However, there are devices that don't work with Linux, for various
>reasons (no specs, too new and no one has written a driver, etc...),
>and it's easier to keep track of those devices so that people can
>avoid them (or the hero types can write drivers for them).
>
[...]

>I think (correct me if I'm wrong) the information we would want to
>collect is:
>
>Product Name:
>
>Manufacturer:
>
>Model Number:
>
>Chipset:
>
>How bad it is (1 to 10, 9 being it almost works and has only minor
>bugs):
>
>Reason (no specs, driver still being worked on, ...):
>
>Url for more info:
>
>An email address of yours that we may publish (so that we can contact
>you if someone says "no, that works just fine!"):
>
>Notes:
>
>Ideas/comments/suggestions are welcome at this stage.
>
>  
>
An idea:  To really put some pressure on vendors, also have an entry for
"alternate/better solution" where people can list a way to achieve the
same result with someone else's product and open drivers.  Example:

Product: Matrox parhelia  (a triplehead graphichs card)
Reason: Bad binary-only 2D-only driver
Alternate solution: Achieve triplehead with two radeon cards (1 AGP 
dualhead + 1 PCI) instead!

This will be useful for anyone planning a upgrade but finding their 
favourite
solution on the incompatibility list.  And it'll sure put some pressure 
on the manufacturer
to at least get a _good_ driver out (changing the reason), or even 
better, an open one
which get rid of the incompatibility entry. 

Helge Hafting

Re: Linux Incompatibility List

[David N. Welton]

Helge Hafting <helge.hafting@hist.no> writes:

> An idea: To really put some pressure on vendors, also have an entry
> for "alternate/better solution" where people can list a way to
> achieve the same result with someone else's product and open
> drivers.  Example:

> Product: Matrox parhelia  (a triplehead graphichs card)
> Reason: Bad binary-only 2D-only driver

Please add it here, using the 'template'.

http://leenooks.com/19

> Alternate solution: Achieve triplehead with two radeon cards (1 AGP
> dualhead + 1 PCI) instead!

> This will be useful for anyone planning a upgrade but finding their
> favourite solution on the incompatibility list.  And it'll sure put
> some pressure on the manufacturer to at least get a _good_ driver
> out (changing the reason), or even better, an open one which get rid
> of the incompatibility entry. Helge Hafting

And in the case where there are multiple possibilities?  I think as a
general rule, I don't want to get into pushing anyone's hardware as an
alternative, although if someone were to mention a few alternatives in
the comments or notes section I don't think it would hurt.

Thanks,
-- 
David N. Welton
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/
       Photos: http://www.dedasys.com/photos/

Re: Linux Incompatibility List

[Helge Hafting]

David N. Welton wrote:

>Helge Hafting <helge.hafting@hist.no> writes:
>
>  
>
>>An idea: To really put some pressure on vendors, also have an entry
>>for "alternate/better solution" where people can list a way to
>>achieve the same result with someone else's product and open
>>drivers.  Example:
>>    
>>
>
>  
>
>>Product: Matrox parhelia  (a triplehead graphichs card)
>>Reason: Bad binary-only 2D-only driver
>>    
>>
>
>Please add it here, using the 'template'.
>
>http://leenooks.com/19
>
>  
>
Done.  I didn't recommend any particular brand when describing
the "alternate solution", as you didn't want that.  The reason for
specifying a brand was only to create more pressure than
"use a couple of supported cards instead".

Helge Hafting

Re: Linux Incompatibility List

[David N. Welton]

Helge Hafting <helge.hafting@hist.no> writes:

> >>Product: Matrox parhelia  (a triplehead graphichs card)
> >>Reason: Bad binary-only 2D-only driver

> >Please add it here, using the 'template'.

> >http://leenooks.com/19

> Done.  I didn't recommend any particular brand when describing the
> "alternate solution", as you didn't want that.  The reason for
> specifying a brand was only to create more pressure than "use a
> couple of supported cards instead".

It's certainly not a bad idea - maybe if we put it right next to the
stupid google ad it would make it return something that made sense
instead of the very hardware we are telling people to avoid.

On the other hand, the site and ads are not something I'm doing to get
rich, so I'd rather avoid even giving the impression of impropriety.

Thanks for adding the card!
-- 
David N. Welton
Personal:                   http://dedasys.com/davidw/
Apache Tcl:                 http://tcl.apache.org/
Free Software:              http://dedasys.com/freesoftware/
Linux Incompatibility List: http://leenooks.com/

Re: Linux Incompatibility List

[linux]

> True, however, their video cards *DO* work on linux (even though it is
> binary-only).  I have a laptop that has the chip.  Does any broadcom
> wireless chip work on linux (ndis wrapper or that piece of junk from
> linuxant doesn't count)

No, they do NOT work on Linux.
They work on current versions of linux-x86 and linux-x86_64.

To "work on linux" without qualification, they have work (or be fixable to
work) work on any port of Linux which can reasonably plug the hardware in.

Re: Linux Incompatibility List

[Wakko Warner]

> > True, however, their video cards *DO* work on linux (even though it is
> > binary-only).  I have a laptop that has the chip.  Does any broadcom
> > wireless chip work on linux (ndis wrapper or that piece of junk from
> > linuxant doesn't count)
> 
> No, they do NOT work on Linux.
> They work on current versions of linux-x86 and linux-x86_64.
> 
> To "work on linux" without qualification, they have work (or be fixable to
> work) work on any port of Linux which can reasonably plug the hardware in.

The specific card in my laptop does work with XFree's latest nVidia drivers,
just not in 3D mode.  It would be a card I'd stay away from, but unlike
broadcom, the cards *DO* work to some extent.  (That card is a GeForce2 Go)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Linux Incompatibility List

[Horst von Brand]

Wakko Warner <wakko@animx.eu.org> said:

[...]

> The specific card in my laptop does work with XFree's latest nVidia drivers,
> just not in 3D mode.  It would be a card I'd stay away from, but unlike
> broadcom, the cards *DO* work to some extent.  (That card is a GeForce2
Go)

Mine is a Geforce FX (Toshiba Satellite M30), and Xorg (Fedora Core 2)
works (sort of). I don't see any use for 3D on a laptop, so just 2D is no
problem to me. But I haven't been able to get 1280x800 working right (it
does a distorted 1024x768), so I use nVidia's driver (which has its own
problems, if you install it for one kernel it breaks for the others).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Linux Incompatibility List

[Robin Rosenberg]

On Sunday 22 August 2004 18.43, you wrote:
> does a distorted 1024x768), so I use nVidia's driver (which has its own
> problems, if you install it for one kernel it breaks for the others).

Instread of rerunning the full installer everytime you can use --extract-only. 
Then run the installer in and for new kernels cd down to 
<installerdir>/usr/src/nv and make install. That won't delete the
module for other kernels. If paranoid, touch *.c first.

-- robin