| |||||||||||||
OLS: The state of Linux wireless networkingOLS: The state of Linux wireless networkingPosted Jul 30, 2008 17:55 UTC (Wed) by jebba (✭ supporter ✭, #4439)In reply to: OLS: The state of Linux wireless networking by ernstp Parent article: OLS: The state of Linux wireless networking
This list may help: http://www.fsf.org/resources/hw/net/wireless/cards.html
(Log in to post comments)
OLS: The state of Linux wireless networking Posted Jul 30, 2008 19:22 UTC (Wed) by rpil2 (guest, #49526) [Link] It seems a reasonable start, but it's not exactly user-friendly. I would think that most people want to know either 1) I have a piece of hardware, does it work with linux/how do i get it to work? (ie what features are supported? what modules do i need? what kernel/distro version do i need) or 2) I want to buy a piece of hardware, what (supported) options do i have? (ie which models work, where do I buy them, how much are they?) but that page doesn't seem to be very useful for either of those. In fact, there's a massive opportunity for someone to make a very useful sight to answer those questions for general hardware
OLS: The state of Linux wireless networking Posted Aug 1, 2008 0:08 UTC (Fri) by giraffedata (subscriber, #1954) [Link] In fact, there's a massive opportunity for someone to make a very useful site to answer those questions for general hardware It seems that way to me too, and I also think it should be easy to gather the data, but I've seen several attempts at this just fail. And some people have gone further and made a business of selling the actual hardware, warranted to work on Linux. They didn't succeed either. I can't even find a reliable way to figure out, given that a device I have is usable in Linux, what module to load as its device driver. In the Windows world you can just go to the vendor's website, look up the model number, and grab it.
OLS: The state of Linux wireless networking Posted Aug 2, 2008 10:56 UTC (Sat) by tialaramex (subscriber, #21167) [Link] I can't even find a reliable way to figure out, given that a device I have is usable in Linux, what module to load as its device driver. In the Windows world you can just go to the vendor's website, look up the model number, and grab it. Unless the device in question is something archaic, like a pre-PNP era ISA board, or you are hand-rolling a tiny Linux distro with minimal tools for some embedded hardware - you don't need to figure this out, the module system will do it for you automatically. Driver modules contain aliases like (pci:v000010B9d00005288sv*sd*bc*sc*i*) which match the hotplug events generated when such a device is inserted or noticed at boot-up. e.g. type 'modinfo ahci' and you'll see it has aliases for a number of devices which we know support AHCI, plus a line which matches any unknown PCI (or PCIe, ExpressCard, mini-PCI etc.) device which claims to offer the AHCI sub-class. When you "go to the vendor's website and grab it" usually you get a bundle which may contain two or more drivers, and that bundle also contains the equivalent plug-and-play information for Windows to perform this same driver matching trick, so there's no difference here. If you mean it would be nice to know where to look on the web for that driver, well, for ordinary users that's not very helpful because they don't want to download an out-of-tree Linux driver and learn how to compile it, so they're mostly going to wait until their vendor includes it at which point it ought to Just Work.
OLS: The state of Linux wireless networking Posted Aug 2, 2008 18:12 UTC (Sat) by cortana (subscriber, #24596) [Link] Because I'm always forgetting this information when trying to trouble shoot others' systems... 1. Find the device in the sysfs. For instance, my wireless network card corresponds to '/sys/devices/pci0000:00/0000:00:0f.0/'. 2. Examine the 'modalias' file in this directory. 3. Run /sbin/modprobe -v -n --first-time $(< /sys/devices/pci0000:00/0000:00:0f.0/modalias). This shows you the module that will be loaded for this hardware. You can also do this by hand... 1. Find the device in the output of 'lspci -nn'. 2. Note the pair of numbers on the end of the line. These are the vendor and device IDs that uniquely identify the device. 3. Look this information up in /lib/modules/$yourkernel/modules.pcimap The same approaches work for USB and presumably all other modern/sensible hardware.
OLS: The state of Linux wireless networking Posted Aug 2, 2008 19:53 UTC (Sat) by giraffedata (subscriber, #1954) [Link] That's great information; I have filed it where there's a chance I will find it next time I have this problem.I'm in the tiny system boat -- not that I'm working with an embedded system, but it's still more cost than it's worth to include a device driver for a device that there's only a one in a thousand chance I'll ever have. So when I do add a device, I have this exercise of determining which driver it needs (and if one even exists). It looks like a modules.pcimap from a full, current Linux system is the directory I've been looking for. Incidentally, an important class of device driver that isn't covered by this is X video controller drivers. I recently changed a video controller, on what I think is a fully conventional Debian system, and it was a more-painful-than-Windows experience getting Linux (i.e. x.org) to work with it. And even then, it would not do DVI, which I eventually concluded is because Linux driver software that can do that simply doesn't exist. That's an example of the problem that started this thread: How do you know what works and what doesn't on Linux -- even with modules.pcimap?
OLS: The state of Linux wireless networking Posted Aug 2, 2008 20:23 UTC (Sat) by tialaramex (subscriber, #21167) [Link] The X video drivers are also supposed to be auto-selected based on a similar principle. You don't specify what type of video hardware you had, so we can only speculate as to why it didn't work but you don't need to configure modern X servers to make them work. Without a configuration the server should detect your PCI/AGP/PCIe etc. graphics chipset and load the appropriate driver, and the driver should (if your display is switched on) pick the right output and a working video mode. Thus, try removing the configuration file and starting the X server. If this doesn't work in current X.org, and you have a card which is actually supported at all, you should report it as a bug, attaching the X server logs. Annoyingly there are a few things which won't work correctly without a configuration file, but it should at least be usable and you should consider filing bugs about anything that doesn't work (I have an open bug about the R400 driver defaulting to XAA then complaining that XAA is unsupported and suffering some redraw bugs as a result) The latest chipsets from the major vendors don't work (or work poorly) unless you are willing to use the vendor's proprietary drivers (and in that case any problems should be taken up with them). Don't buy stuff aimed at Windows gamers with too much money. The mention of DVI makes me wonder if you had something more serious wrong though, DVI ought to work with the hardware-specific drivers for Intel or ATI hardware old enough to be supported, or even with a lot of nVidia cards - you are seeing text through this DVI connector prior to X starting, right ?
Linux device driver availability (wasOLS: The state of Linux wireless networking) Posted Aug 2, 2008 21:23 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Thus, try removing the configuration file and starting the X server. I ultimately did essentially that. But if you have to remove a file in order to use a new video controller, you're already in more-painful-than-Windows territory. Especially if you have to find an expert like you to tell you to do it. The mention of DVI makes me wonder if you had something more serious wrong though, DVI ought to work with the hardware-specific drivers for Intel or ATI hardware old enough to be supported, or even with a lot of nVidia cards - you are seeing text through this DVI connector prior to X starting, right ? No, I've never seen anything come out of the DVI connector, and I tried every scenario except putting the card in a Windows machine. It's a Matrox G400; the 'mga' driver man page, and some morsels I found on the web, suggest that you have to specifically turn on DVI and the only known software that can do that is a closed source X module from Matrox and Matrox does not offer a version compatible with the X server in my Debian Etch system. This is just the card that was laying around. But if I had set out to buy something to drive my DVI monitor, I don't know how I would have known what to choose.
Linux device driver availability (wasOLS: The state of Linux wireless networking) Posted Aug 3, 2008 9:13 UTC (Sun) by tialaramex (subscriber, #21167) [Link] Well, I guess my point was more that the distro oughtn't to create this file in the first place. One of X.org's biggest problems these days seems to be the little programs that Linux distributors knocked together in Perl or C ten years ago that try to create a "correct" configuration, often at install time. Obviously anything that the distro manually configures at install time and which subsequently needs changing is going to be a pain for the user. We can't really blame the distributors for doing this back when XFree86 wasn't smart enough to just pick a working driver and configure it, but we can blame them for not re-assessing this decision some time between when X was first able to run without configuration and today. By the point when Etch was released such a file was necessary for only a tiny minority of users, and so it should not be written by default. You won't have to remove the file again - it should stay gone (unless sadly you have to recreate it due to one of the outstanding limitations of the auto-configured X server, but fixing these ought to be a priority) I have to say I did not realise that they made G400s with DVI, I guess it figures given the niche where Matrox makes money but it was still a surprise to me. My G400 just had a single VGA output. Yeah, that chipset is not well supported and mine has been in a junk pile for some number of years. Apparently its video BIOS doesn't enable the DVI output (else you'd see something) so that means it's not just Linux, any OS without explicit support for that hardware won't work with DVI on that chip, which is pretty sad. I don't think there's much chance that anyone will look at a nearly 10 year old chip now and think "Ooh, reverse engineering the DVI output looks like a fun project for a rainy weekend" so you may be SOL, sorry. And I can see how you'd feel misled, the G400 is documented as working, without a caveat about that DVI output.
X configuration files, DVI on the G400 Posted Aug 8, 2008 12:40 UTC (Fri) by anton (guest, #25547) [Link] Yes, on all the Radeon cards I have tried Debian (and its derivatives) creates an xorg.conf file that does not work, and if I delete it and start X, the card just works beautifully. Its as if Debian and its derivatives were staffed by Nvidia employees.Concerning the Matrox G400, I used to use a G450, and its DVI output has a rather limited bandwidth that allows only 1280x1024 with regular modes. I used a special mode to make it display 1600x1200.
OLS: The state of Linux wireless networking Posted Aug 4, 2008 11:26 UTC (Mon) by daenzer (✭ supporter ✭, #7050) [Link] > (I have an open bug about the R400 driver defaulting to XAA then > complaining that XAA is unsupported and suffering some redraw bugs as a > result) Which bug report is that? The radeon driver doesn't say that XAA is unsupported but that RENDER acceleration is unsupported with XAA (on >= R300 cards). As for XAA rendering corruption, make sure its offscreen pixmap support is disabled (the default in current X servers).
OLS: The state of Linux wireless networking Posted Aug 2, 2008 20:04 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
Ooh, modalias, I did not know that was there. I knew about modules.{pcimap,usbmap} and so on,
but not the sysfs modalias feature. Neat.
|
|||||||||||||