If you have a new shiny webcam or some other device you want to use in Linux, here is a quick short guide how you can have it runnig within minutes with a bit of luck.
Showing posts with label drivers. Show all posts
Showing posts with label drivers. Show all posts
Always full of Surprises - Intel Linux Wireless Drivers
You always think that device support is very good in Linux for old drivers. You think that Intel wireless drivers are especially well supported. So an old intel wireless device should have eccelent support. But it turns out I was wrong in this case. Intel took from August 2010 until the end of Apri 2011 to fix a regression in their driver covering several devices introduced in 2.6.35, now in 2.6.39 it's fixed it seems.
New Open Source Poulsbo Driver in 2.6.39 staging
It works pretty nicely - though just as a framebuffer device so far. A specialized Xorg userspace driver for the new staging kernel driver is expected sometime soon. It already supplies KMS and can be used with the fbdev driver of Xorg. So next time you want to try a new kernel you can at least get into a working X without much ado. And there will surely be at least a simple driver coming with new kernels now. The first steps have been taken. And of course, all this is hopefully just the beginning...
What Linux means for the Consumer - Drivers, Open Source and Support
When a consumer installs a Linux system, this has various consequences for him, which are sometimes hard to estimate at first. I've written a little summary touching the differences to Windows and Mac OS X in drivers, open source and support.
Drivers
Linux is not yet as far spread as Operating Systems like Windows or Mac OS X. This means that hardware corporations which have little money or skilled staff usually don't publish their own Linux driver and ship it along with the hardware when you buy it. In short: There currently is usually no driver disk for Linux.
But that's not really as a big a problem as it seems at first. One point is that - especially if the poor or skill lacking company is smart and publishes detailed product specifications - drivers are often written by the community. This has the disadvantage that it takes longer and when a device is first release, there is not usually no driver ready yet.
But it also has several advantages: Once drivers are written, they are usually open source. For the advantages, see below in my next point. And the drivers eventually are often better and more extensive than the drivers delivered by the hardware manufacturer. E.g. the bttv drivers of my TV card worked much better and longer than their Windows counterparts. And there was even an additional driver not present in Windows for a sound chip on the TV card to digitalize TV and line input sound up to a rate of 192 Khz -- for a TV card produced in 199X! My current sound card - using the snd-hda-intel driver - for some reason has a significantly better sound in Linux than in Windows, where it pretty much lacks any bass.
A huge advantage is the common API of drivers. In Windows every manufacturer writes his own drivers with their own API, and their own software to use the API. E.g. A DVB-T digital TV card has a Windows driver, and a special decoding and recording software for each and every single card. Sometimes the main chip and driver comes from the same manufacturer for several cards. But it's still often difficult if possible at all to use another software than the one supplied by the manufacturer.
In Linux, there is a common DVB interface. This means you can not only use the same software for all DVB-T receivers, you can even often use the same for DVB-T(errestrial), DVB-S(atellite), and DVB-C(abel). And it makes perfect sense that instead of tens of quickly written (and often buggy) different applications for different cards, you have a selection of a few really good programs. (E.g. Tvtime and others for analog, Kaffeine and others for digital reception -- and I mean for all supported ones).
In Windows, if there is a new group of popular hardware, like WIFI or Digital TV adapters, you need to wait for Microsoft to release a common API and hope they do. That's likely to happen only in the next Windows Version (e.g. XP, Vista). And then everything must be backwards compatible. This means that a better API might not be introduced for Windows XP ever, and advantages for new APIs are restricted by the requirement that all old APIs have to still work exactly the way they did. With open source drivers in the kernel tree, you can just modify the drivers along with the API. It's all in the same place and some changes are simply a matter of "search and replace".
Once a good open source driver exists, and especially if it gets integrated into one of the main driver projects, it usually works out of the box. This means you start Linux, even from a Live CD, and the hardware, e.g. a sound card, scanner or TV card just immediatelly works without any fuss like driver installation or configuration. It's not like installing Windows and then downloading the drivers for all your software, but if the driver is well supported, it just all works after installing the sytem. That's why Live CDs are so useful to test the Linux compatibility of a computer's hardware. And another great thing is that these integrated drivers are automatically updated for you - for Ubuntu even without the need to reboot (for other distributions you need to pay for this feature). This prevents security risks, which are much more rare in Linux, anyway.
Open Source
Open Source is a guarantee that a good product can have a long life-time. Drivers are one excellent example. If you have an open source driver, and it's of good quality and integrated into the Linux kernel or one of the main user land driver projects (SANE, CUPS, ALSA), you will have a driver for a very, very long time. This means that unlike with Microsoft and Mac OS X systems, you will not need to buy a new scanner, because you can't find a driver for Windows 7 or the "Snow Leopard", but quite the contrary the driver usually gets better and better and you often have no problems whatsoever with using a 10 years or older scanner, printer, sound card, TV card, etc with the newest Windows version.
My DVB-T adapter has lots of features it lacks in Windows, including recording up to 4 channels in one bouquet at once, 50 fps deinterlacing, hardware accelerated video decoding, automatic scheduled recording, etc. I just got a new sound card, which uses a lot less CPU and doesn't have a few of the Windows issues like skipping and beeping during playback. Even the pretty new Intel poulsbo chipset already works better for me in Linux now than in Windows (lower battery consumption, better video scaling and hardware accelerated video playback, much faster resume from suspend (feels like 1 second max, dmesg says 2.5 seconds; Windows takes a felt 4-15 seconds), ...). Thanks to Linux my Netbook is now a full featured surround sound FullHD video center and it consumes even less battery than in Windows.
But open source also means that things are customizable. This would of course also mean that if you can program yourself you can potentially modify and fix as many issues with software and drivers as your skills permit. And this is one of the main driving forces of Open Source. But it also means that if there is a problem, the fix can be applied where it makes the most sense. Let's make another example in comparison to Windows.
In Windows if there is a bug in the suspend to ram mechanism, which causes problems for a certain hardware, this is quite hard to figure out in the first place. Because you don't know how the Windows mechanism works. If it was publicly known, Linux would have a much easier way with ensuring suspend to ram compatibility for more hardware. Once you figure out where the problem is in Windows, you still have no way of fixing the problem where it occurs.
Because you can't modify any Windows components. That's completely different in Linux - here anyone can modify anything. I once wrote a small Linux kernel patch myself, and I'm really not that much of a programmer. But with the help of some kernel developers I fixed my own problem and then posted my first Linux kernel patch.
Another great example is powertop. It's a tool to check what decreases your battery time in Linux by looking into which applications wake up your CPU from power saving modes and how often. For this to work the kernel had to be modified. Once this was done you could find out which programs are the main cause. And then, because they are also usually open source, you could modify them as well so they don't wake up the processor as often. And that's how my netbook now consumes less power - in some scenarious a lot less - in Linux than in Windows. All this would not be possible in a closed source world. The same is now done for latency with latencytop btw.
Support
The disadvantage with support in Linux and Open Source is that if you don't pay for it, you won't get people who will treat you like you paid for it. This means it's very un-wise to contact driver or other software developers and say: "You've got to fix this!" Because they really, really don't have to. They are in no way obligated to you. You should always remember that. Only some people get paid for their work for open source at all. Many start a project and keep working it to scrach and itch (see here, and here). And I think it's how Linus started the Linux kernel project sometime long ago. If you want support that treats you like you've paid for it - get paid support!
But the big advantage in Linux support is that if you have a clue, you have access to incredibly smart people. You can talk directly to the developers and they usually know their stuff really, really well. Yes it can be a problem to get an answer sometimes, but if you've read the manual, you really know what you're doing, keep in mind that you didn't pay them and appropriately contact them very politely, you will be amazed how much is possible.
I still remember how helpful, friendly and patient the KDE plasma developers were when I wrote my first plasma-applet. I remember how the Linux kernel developers take every issue seriously and try to help you find the problem, especially with regressions.
And in my view it's so incredibly much better than most hardware manufacturers who you pay with buying their products to get support. You usually first get stuck with incompetent telephone support and are really lucky if you ever get to contact the driver developers or someone anywhere near them. And then those driver developers usually get their money for writing bleeding edge new drivers for new hardware, or they need to write a driver that's compatible with the newest Windows release (without really knowing how everything works on the Windows side).
They usually have little patience and understanding for a not working driver in some system and say that your supplier should fix the issues. (E.g. NVIDIA would say the graphics card manufacturer should fix the problem and Intel would say your Notebook manufacturer should deal with the problems.) But open source developers will usually understand you well, because that's often why they wrote the driver in the first place, so as many people can use it without problems as possible. Here the problem is usually not the lack of will, but of your politeness, your and their time and other resources.
Conclusion
You have to ensure that hardware is Linux compatible before you buy it. If you're lucky and you find open source driver integrated into the Linux kernel or one of the main driver projects, you are most likely to be able to really enjoy your hardware in Linux for a very, very, very long time and there will be no need miss out on the newest features and software coming for free with the newest release of your favorite distribution. If something doesn't work you're expected to do your part and google and try everything you can to fix it, including postings in a forum and on a user mailing list before contacting the developers. This way they have more time for and fun with actually fixing the problem.
But it also means that for not paying for Windows and the drivers, you can't expect the same support. If you want the same level of support, try offering money to the developers you want the support from (paypal helps) or buy a support service. I'm sure they're much more likely to help you in a way similar or better than Windows then.
I'm happy about your thoughts and comments. And remember I don't get paid for writing this either - as you can't even see ads on this page.
All trademarks belong to their respective owners, not to me.
(Windows, Windows XP and Windows Vista->Microsoft, Mac OS X -> Apple, Linux to Linus Torvalds etc.).
Drivers
Linux is not yet as far spread as Operating Systems like Windows or Mac OS X. This means that hardware corporations which have little money or skilled staff usually don't publish their own Linux driver and ship it along with the hardware when you buy it. In short: There currently is usually no driver disk for Linux.
But that's not really as a big a problem as it seems at first. One point is that - especially if the poor or skill lacking company is smart and publishes detailed product specifications - drivers are often written by the community. This has the disadvantage that it takes longer and when a device is first release, there is not usually no driver ready yet.
But it also has several advantages: Once drivers are written, they are usually open source. For the advantages, see below in my next point. And the drivers eventually are often better and more extensive than the drivers delivered by the hardware manufacturer. E.g. the bttv drivers of my TV card worked much better and longer than their Windows counterparts. And there was even an additional driver not present in Windows for a sound chip on the TV card to digitalize TV and line input sound up to a rate of 192 Khz -- for a TV card produced in 199X! My current sound card - using the snd-hda-intel driver - for some reason has a significantly better sound in Linux than in Windows, where it pretty much lacks any bass.
A huge advantage is the common API of drivers. In Windows every manufacturer writes his own drivers with their own API, and their own software to use the API. E.g. A DVB-T digital TV card has a Windows driver, and a special decoding and recording software for each and every single card. Sometimes the main chip and driver comes from the same manufacturer for several cards. But it's still often difficult if possible at all to use another software than the one supplied by the manufacturer.
In Linux, there is a common DVB interface. This means you can not only use the same software for all DVB-T receivers, you can even often use the same for DVB-T(errestrial), DVB-S(atellite), and DVB-C(abel). And it makes perfect sense that instead of tens of quickly written (and often buggy) different applications for different cards, you have a selection of a few really good programs. (E.g. Tvtime and others for analog, Kaffeine and others for digital reception -- and I mean for all supported ones).
In Windows, if there is a new group of popular hardware, like WIFI or Digital TV adapters, you need to wait for Microsoft to release a common API and hope they do. That's likely to happen only in the next Windows Version (e.g. XP, Vista). And then everything must be backwards compatible. This means that a better API might not be introduced for Windows XP ever, and advantages for new APIs are restricted by the requirement that all old APIs have to still work exactly the way they did. With open source drivers in the kernel tree, you can just modify the drivers along with the API. It's all in the same place and some changes are simply a matter of "search and replace".
Once a good open source driver exists, and especially if it gets integrated into one of the main driver projects, it usually works out of the box. This means you start Linux, even from a Live CD, and the hardware, e.g. a sound card, scanner or TV card just immediatelly works without any fuss like driver installation or configuration. It's not like installing Windows and then downloading the drivers for all your software, but if the driver is well supported, it just all works after installing the sytem. That's why Live CDs are so useful to test the Linux compatibility of a computer's hardware. And another great thing is that these integrated drivers are automatically updated for you - for Ubuntu even without the need to reboot (for other distributions you need to pay for this feature). This prevents security risks, which are much more rare in Linux, anyway.
Open Source
Open Source is a guarantee that a good product can have a long life-time. Drivers are one excellent example. If you have an open source driver, and it's of good quality and integrated into the Linux kernel or one of the main user land driver projects (SANE, CUPS, ALSA), you will have a driver for a very, very long time. This means that unlike with Microsoft and Mac OS X systems, you will not need to buy a new scanner, because you can't find a driver for Windows 7 or the "Snow Leopard", but quite the contrary the driver usually gets better and better and you often have no problems whatsoever with using a 10 years or older scanner, printer, sound card, TV card, etc with the newest Windows version.
My DVB-T adapter has lots of features it lacks in Windows, including recording up to 4 channels in one bouquet at once, 50 fps deinterlacing, hardware accelerated video decoding, automatic scheduled recording, etc. I just got a new sound card, which uses a lot less CPU and doesn't have a few of the Windows issues like skipping and beeping during playback. Even the pretty new Intel poulsbo chipset already works better for me in Linux now than in Windows (lower battery consumption, better video scaling and hardware accelerated video playback, much faster resume from suspend (feels like 1 second max, dmesg says 2.5 seconds; Windows takes a felt 4-15 seconds), ...). Thanks to Linux my Netbook is now a full featured surround sound FullHD video center and it consumes even less battery than in Windows.
But open source also means that things are customizable. This would of course also mean that if you can program yourself you can potentially modify and fix as many issues with software and drivers as your skills permit. And this is one of the main driving forces of Open Source. But it also means that if there is a problem, the fix can be applied where it makes the most sense. Let's make another example in comparison to Windows.
In Windows if there is a bug in the suspend to ram mechanism, which causes problems for a certain hardware, this is quite hard to figure out in the first place. Because you don't know how the Windows mechanism works. If it was publicly known, Linux would have a much easier way with ensuring suspend to ram compatibility for more hardware. Once you figure out where the problem is in Windows, you still have no way of fixing the problem where it occurs.
Because you can't modify any Windows components. That's completely different in Linux - here anyone can modify anything. I once wrote a small Linux kernel patch myself, and I'm really not that much of a programmer. But with the help of some kernel developers I fixed my own problem and then posted my first Linux kernel patch.
Another great example is powertop. It's a tool to check what decreases your battery time in Linux by looking into which applications wake up your CPU from power saving modes and how often. For this to work the kernel had to be modified. Once this was done you could find out which programs are the main cause. And then, because they are also usually open source, you could modify them as well so they don't wake up the processor as often. And that's how my netbook now consumes less power - in some scenarious a lot less - in Linux than in Windows. All this would not be possible in a closed source world. The same is now done for latency with latencytop btw.
Support
The disadvantage with support in Linux and Open Source is that if you don't pay for it, you won't get people who will treat you like you paid for it. This means it's very un-wise to contact driver or other software developers and say: "You've got to fix this!" Because they really, really don't have to. They are in no way obligated to you. You should always remember that. Only some people get paid for their work for open source at all. Many start a project and keep working it to scrach and itch (see here, and here). And I think it's how Linus started the Linux kernel project sometime long ago. If you want support that treats you like you've paid for it - get paid support!
But the big advantage in Linux support is that if you have a clue, you have access to incredibly smart people. You can talk directly to the developers and they usually know their stuff really, really well. Yes it can be a problem to get an answer sometimes, but if you've read the manual, you really know what you're doing, keep in mind that you didn't pay them and appropriately contact them very politely, you will be amazed how much is possible.
I still remember how helpful, friendly and patient the KDE plasma developers were when I wrote my first plasma-applet. I remember how the Linux kernel developers take every issue seriously and try to help you find the problem, especially with regressions.
And in my view it's so incredibly much better than most hardware manufacturers who you pay with buying their products to get support. You usually first get stuck with incompetent telephone support and are really lucky if you ever get to contact the driver developers or someone anywhere near them. And then those driver developers usually get their money for writing bleeding edge new drivers for new hardware, or they need to write a driver that's compatible with the newest Windows release (without really knowing how everything works on the Windows side).
They usually have little patience and understanding for a not working driver in some system and say that your supplier should fix the issues. (E.g. NVIDIA would say the graphics card manufacturer should fix the problem and Intel would say your Notebook manufacturer should deal with the problems.) But open source developers will usually understand you well, because that's often why they wrote the driver in the first place, so as many people can use it without problems as possible. Here the problem is usually not the lack of will, but of your politeness, your and their time and other resources.
Conclusion
You have to ensure that hardware is Linux compatible before you buy it. If you're lucky and you find open source driver integrated into the Linux kernel or one of the main driver projects, you are most likely to be able to really enjoy your hardware in Linux for a very, very, very long time and there will be no need miss out on the newest features and software coming for free with the newest release of your favorite distribution. If something doesn't work you're expected to do your part and google and try everything you can to fix it, including postings in a forum and on a user mailing list before contacting the developers. This way they have more time for and fun with actually fixing the problem.
But it also means that for not paying for Windows and the drivers, you can't expect the same support. If you want the same level of support, try offering money to the developers you want the support from (paypal helps) or buy a support service. I'm sure they're much more likely to help you in a way similar or better than Windows then.
I'm happy about your thoughts and comments. And remember I don't get paid for writing this either - as you can't even see ads on this page.
All trademarks belong to their respective owners, not to me.
(Windows, Windows XP and Windows Vista->Microsoft, Mac OS X -> Apple, Linux to Linus Torvalds etc.).
Intel Poulsbo Frustration Continues a Year Later
I'm also frustrated. I happily bought my netbook about exactly a year ago as many others in the hope that Intel would provide a well working open source driver, at least excluding 3d and VAAPI. Then I managed to get it running at all and then including 3d and vaapi (see http://linux-tipps.blogspot.com/2009/12/vaapi-accelerated-hd-video-on-msi-wind.html) and i was quite happy.
But I never managed to get several things to work:
Does anyone know how to fix any of this?
Now I have the crazy situation that in Windows XP I can use standby and 3d but no HD, and in Linux I have better quality and VAAPI HD video playback and 3d, but no standby. And I'm frustrated.
It's such a nice netbook and performs so well otherwise, it's really sad and frustrating if drivers keep you from really enjoying what you bought.
I don't even know if and how long I will be update my OS. It's already unclear if I would lose VAAPI and/or 3D acceleration when I upgrade to Kubuntu 10.04 -- if X would still work at all. But I have no idea how long drivers will still be developed or at least maintained if there is no open source version.
So please Intel, if not an open source driver then at least release open source specs!!!
Update
I've actually managed to get standby working pretty reliably. The computer returns back from standby with amazing speed, too. The trick was to update the bios to the newest version. This fixes prior crashes during resume. But the crashes in Windows XP when I try to use DXVA persist.
Now the problem is that my wifi and sound drivers are still problematic after resume. My wifi driver causes kernel panics and my audio driver simply stops working...
But I never managed to get several things to work:
- reliable standby (works once or twice if I haven't used 3d or vaapi)
- backlight regulation.
Does anyone know how to fix any of this?
Now I have the crazy situation that in Windows XP I can use standby and 3d but no HD, and in Linux I have better quality and VAAPI HD video playback and 3d, but no standby. And I'm frustrated.
It's such a nice netbook and performs so well otherwise, it's really sad and frustrating if drivers keep you from really enjoying what you bought.
I don't even know if and how long I will be update my OS. It's already unclear if I would lose VAAPI and/or 3D acceleration when I upgrade to Kubuntu 10.04 -- if X would still work at all. But I have no idea how long drivers will still be developed or at least maintained if there is no open source version.
So please Intel, if not an open source driver then at least release open source specs!!!
Update
I've actually managed to get standby working pretty reliably. The computer returns back from standby with amazing speed, too. The trick was to update the bios to the newest version. This fixes prior crashes during resume. But the crashes in Windows XP when I try to use DXVA persist.
Now the problem is that my wifi and sound drivers are still problematic after resume. My wifi driver causes kernel panics and my audio driver simply stops working...
USB Surround Sound in Linux
It's an annoying topic. Not many USB surround sound cards exist anyway, even less of those are good ones. But after an hour of searching the web and reading various articles, I've finally found a USB surround sound card that works well in Linux:
Terratec Aureon 5.1 USB MK-II
Usually the problem is that terratec's drivers are not too good. Luckily, the Linux drivers are often excellent due to the open source community's investments in them. And here the case is similar: Terratec was smart enough to use the standard USB interface, so they need not write drivers for any OS and the Linux USB Audio driver works perfectly - already for a long time.
But German reviews on Amazon suggest that the digital output does not work with surround sound, but only stereo. This means it's just an option if you want analogue sound.
"Enforce USB bandwidth allocation (EXPERIMENTAL)" must be deactivated in the kernel.
If you still need some help with the setup, e.g. for games, try this page.
If you want a really good USB stereo sound card with digital out for Linux (cost "< 20 €"), and you're up for some work, here's a German guide how to build your own.
But according to German Amazon reviews and this website, the
Creative SoundBlaster X-Fi Surround 5.1 USB
is also supported in Linux - at least for stereo. A German guide is in the Ubuntu forums, but it seems it should work with any current Linux.
Both cards have driver issues. It seems the Creative card doesn't work well in Vista x64 (no/bad subwoofer sound). I think in the end I will decide for the Creative card anyway. It's much newer and probably has better sound than the much older Terratec box.
Terratec Aureon 5.1 USB MK-II
Usually the problem is that terratec's drivers are not too good. Luckily, the Linux drivers are often excellent due to the open source community's investments in them. And here the case is similar: Terratec was smart enough to use the standard USB interface, so they need not write drivers for any OS and the Linux USB Audio driver works perfectly - already for a long time.
But German reviews on Amazon suggest that the digital output does not work with surround sound, but only stereo. This means it's just an option if you want analogue sound.
"Enforce USB bandwidth allocation (EXPERIMENTAL)" must be deactivated in the kernel.
If you still need some help with the setup, e.g. for games, try this page.
If you want a really good USB stereo sound card with digital out for Linux (cost "< 20 €"), and you're up for some work, here's a German guide how to build your own.
But according to German Amazon reviews and this website, the
Creative SoundBlaster X-Fi Surround 5.1 USB
is also supported in Linux - at least for stereo. A German guide is in the Ubuntu forums, but it seems it should work with any current Linux.
Both cards have driver issues. It seems the Creative card doesn't work well in Vista x64 (no/bad subwoofer sound). I think in the end I will decide for the Creative card anyway. It's much newer and probably has better sound than the much older Terratec box.
Poulsbo is Already working on Ubuntu 10.04
It's not a flawless support and currently without 3D, but there is a poulsbo driver for Ubuntu 10.04. (The link helps for all Ubuntu versions.)
You can download the driver here.
You can download the driver here.
X Video finally works - Poulsbo and Linux on the MSI Wind U110 - Fix for BUG: kernel NULL pointer dereference at 00000000
If you tried to get poulsbo to run on your system and you get a message like this, you should try the fix posted below.
"kernel BUG: unable to handle kernel NULL pointer dereference at 00000000" (2.6.28)
"kernel BUG: unable to handle kernel NULL pointer dereference at (null)" (2.6.31)
if (edid)
....
e.g.
/* if (edid)
drm_add_edid_modes(output, edid); */
Then reconfigure the package and it should be recompiled. The next time you start it, it should work instead of creating kernel BUG
Update:
Xvideo actually works better than in Directx video in Windows XP, where I often see blocky video scaling. The CPU usage is not too high, either. Currently it's only working under Ubuntu 9.04 for me. Though I had managed to compile the module with kernel 2.6.30 before, I don't remember how I did that... And I haven't gotten actual video acceleration to work yet.
Of course I'll keep you updated and I'll post a little howto once it's all working. But feel free to ask, anyway. And thanks so much to the person from the Ubuntu bugzilla who helped me to finally get it all working!!!
Update2: Keep checking the page. I will post a link to an archive with a script that will manage the compilation in Ubuntu 9.10. If someone could help me figure out how to, I'd love to create, upload and post a .deb for dkms so it all works automatically... Or ultimately, we could modify the driver to check for the MSI's signature and then skip the edid check.
I've created a package for Karmic that you can use to manually install the driver with the fix already applied: http://www.megaupload.com/?d=BB23R7K2. Extract it and execute the script make_psb.sh, then reboot and try to modprobe psb. Let me know when the 10 downloads run out and it it works for you.
Update3: Here is a step by step howto. It explains setting up X and then VAAPI (hardware video decoding) in Kubuntu 9.10.
My script for making the psb module out of the package:
My script for making the psb module out of the package:
KERNEL=/lib/modules/`uname -r`/
make KERNELRELEASE="$(uname -r)" LINUXDIR="/lib/modules/$(uname -r)/build" DRM_MODULES=psb || exit 1;
sudo cp drm.ko $KERNEL/kernel/drivers/gpu/drm/drm.ko
sudo mkdir -p $KERNEL/updates/dkms
sudo cp psb.ko $KERNEL/updates/dkms/psb.ko
ls -l $KERNEL/kernel/drivers/gpu/drm/drm.ko $KERNEL/updates/dkms/psb.ko
sudo depmod -a
Why you're screwed with the Intel Poulsbo Chipset
Let me tell you why you're not only screwed when you want to run Poulsbo systems on Linux:
see http://supportmail.intel.com/scripts-emf/defaultlanding.aspx?productid=3180&srchidstr=39,1101,3180 and it seems does no longer supply driver downloads: http://downloadcenter.intel.com/NotFound.aspx?ProductID=3180&lang=eng. Ok, the last is wrong: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProductID=3001&DwnldID=17992&strOSs=45&OSFullName=Windows%20XP%20Home%20Edition*&lang=eng
Now what other support options are there from Intel? Contacting your manufacturer often does not prove helpful either. MSI's support even seem aware that the Poulsbo chipset is supposed to have active video decoding acceleration. They inform that the Poulsbo chipset is not a high end chipset and you shall just disable video decoding acceleration in case it crashes your Windows system.
Considering the overal bad support for the Poulsbo chipset I can not recommend using it: No good Linux driver, no good Windows driver, DXVA announced but not working(not even in Windows), no email support, no Windows driver downloads, etc.
So I think: don't buy Poulsbo systems.
Intel advertises features it can't deliver and doesn't support the chipset. And it's really sad to bring out a chipset that won't be supported well until maybe 2010.
Update: I've finally managed to get poulsbo working on my MSI Wind U110 netbook. Check out the dirty hack and the details.
Canon Printer Tips
Did you know there are original Linux driver from Canon? Now you know that, why not get the hacked and enhanced version.
Disabling Touchpad on Demand
There's now an alternative to using the shared memory of the synaptic driver to enable and disable the touchpad:
xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Synaptics Off" 8 1 (enable)
xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Synaptics Off" 8 0 (disable)
This should work out of the box in Ubuntu 8.10 (Intrepid). But it doesn't. At least not for me. But this works for me:
xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Synaptics Off" 8 0
xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Synaptics Off" 8 1
Nice! :)
Canon Printer Problem "pstocanonij write error,32" Solved
I just had the error message
"pstocanonij write error,32."
when trying to print something with the Original Canon Printer Driver and my MP610. It turned out I needed to cancel the job. I printed a test page and then I printed the same thing again and it worked just fine. Sometimes it hangs up and I have to turn if off and on again.
But I still have no idea why he's cleaning his inks several times a day currently...
Update:
The error comes up more and more often now and I haven't found a real fix yet. It might be related to certain settings. The printer prints one page and then stops printing.
FIX:
You can either use a different driver (e.g. the gutenprint one), or it may be an incorrect page border setting. In my experience, changing the page border settings back to their original settings (31,75mm) fixed the problems. You may have to reboot your computer and turn the printer off and on again for it to work again.
FIX2:
It might also be that your /tmp directory is full. This happens especially when you're using the special tmpfs on that directory, as some distributions automatically do. Or, of course, if you're main partition is out of space.
Broadcom Wireless Drivers - wl vs. b43 - Performance Comparison
I've compared the performance of both drivers with a simple iperf test over a few meters:
Broadcom Proprietary Driver:
TCP
------------------------------------------------------------
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 46362
[ 4] 0.0-10.2 sec 24.6 MBytes 20.2 Mbits/sec
[ 5] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 46363
[ 5] 0.0-10.2 sec 24.6 MBytes 20.2 Mbits/sec
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 46365
[ 4] 0.0-10.2 sec 24.0 MBytes 19.8 Mbits/secUDP
------------------------------------------------------------
Receiving 1470 byte datagrams
UDP buffer size: 375 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 35141[ 3] 0.0-10.0 sec 24.2 MBytes 20.2 Mbits/sec 1.364 ms 0/17239 (0%)[ 3] 0.0-10.0 sec 1 datagrams received out-of-order[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 38437[ 4] 0.0-10.0 sec 27.2 MBytes 22.8 Mbits/sec 1.837 ms 0/19418 (0%)[ 4] 0.0-10.0 sec 1 datagrams received out-of-order[ 3] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 45356[ 3] 0.0-10.0 sec 28.8 MBytes 24.1 Mbits/sec 1.319 ms 0/20555 (0%)[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
B43 Open Source DriverTCP
------------------------------------------------------------
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 42345
[ 4] 0.0-10.1 sec 19.6 MBytes 16.4 Mbits/sec
[ 5] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 42346
[ 5] 0.0-10.2 sec 23.1 MBytes 19.0 Mbits/sec
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 42347
[ 4] 0.0-10.2 sec 21.7 MBytes 17.8 Mbits/secUDP
------------------------------------------------------------
Receiving 1470 byte datagrams
UDP buffer size: 375 KByte (default)
------------------------------------------------------------[ 3] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 57459
[ 3] 0.0-10.1 sec 14.0 MBytes 11.7 Mbits/sec 0.438 ms 152/10171 (1.5%)
[ 3] 0.0-10.1 sec 1 datagrams received out-of-order
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 55062
[ 4] 0.0-10.0 sec 15.7 MBytes 13.1 Mbits/sec 1.372 ms 205/11373 (1.8%)
[ 4] 0.0-10.0 sec 1 datagrams received out-of-order
[ 3] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 49861
[ 3] 0.0-10.1 sec 23.4 MBytes 19.5 Mbits/sec 3.724 ms 292/17017 (1.7%)
[ 3] 0.0-10.1 sec 1 datagrams received out-of-order
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 42069
[ 4] 0.0-10.0 sec 21.5 MBytes 18.0 Mbits/sec 1.370 ms 239/15544 (1.5%)
[ 4] 0.0-10.0 sec 1 datagrams received out-of-order
As you can see, the proprietary driver is slightly faster in TCP mode. And somehow they're both really slow in UDP mode. That's something I'd like to find out more about.
Update: That was my fault. For some reason iperf restricts UDP tests to 1 Mbit/s. Now the results are more appropriate. The result is that the proprietary driver has a more stable connection speed.
But I think that's really not worth installing a proprietary driver. Broadcom really would better integrate the changes into the open source driver. Their driver is still relying on the deprecated wireless system anyway.
Update2: Further tests showed that, at least after a while of usage, the proprietary driver creates high network latencies. Ping times to the router went up from 2 ms to an average of 160ms (peaks of 500ms !).
Broadcom Proprietary Drivers with Linux 2.6.27
I've found a way to get the drivers to compile... I just downloaded the intrepid restricted modules package source from Ubuntu.
Then unpack, go to ubuntu-intrepid-lrm/ubuntu-restricted/broadcom
and make -C /lib/modules/`uname -r`/build M=`pwd`
They only work with TKIP for me, at least not with WPA2. (The open source b43 drivers does.)
Then unpack, go to ubuntu-intrepid-lrm/ubuntu-restricted/broadcom
and make -C /lib/modules/`uname -r`/build M=`pwd`
They only work with TKIP for me, at least not with WPA2. (The open source b43 drivers does.)
Broadcom's Unfree Driver
Broadcom put up some partially binary drivers for their wireless chips. Well, better late and little I guess. They don't compile with 2.6.27 yet, though. Please post hints in the comments.
Intel Wireless Card not working in Ubuntu 8.04
If you've got problems with your intel wireless card, esp. in Ubuntu 8.04, try restarting hal:
This might fix that wireless networks don't show up as well as other problems. Try the key combination for enabling/disabling the wireless card in your notebook again afterwards.
sudo /etc/init.d/hal restart
This might fix that wireless networks don't show up as well as other problems. Try the key combination for enabling/disabling the wireless card in your notebook again afterwards.
New Intel Xorg Driver Released
It seems the intel driver in the Ubuntu repositories is still pretty old. You can download a new one from their website, though and install it manually.
I wish there was an updated package available for hardy. You can probably use the intrepid package again, though. It has version number 2.3.2. Then you can leave the EXA acceleration enabled without the related problems with e.g. Opera.
I wish there was an updated package available for hardy. You can probably use the intrepid package again, though. It has version number 2.3.2. Then you can leave the EXA acceleration enabled without the related problems with e.g. Opera.
b43 broadcom wireless driver
I really wish the b43 driver would work better... I keep losing the connection after a certain time. It is much better in 2.6.25.7 than in 2.6.26.6, but it's still disappointing to keep having to remove and reinsert the module to stay online. I'm really disappointed in Broadcom. The intel wireless drivers are a lot more reliable and obviously broadcom could do much more to ensure its hardware works well in Linux. The b43 team still does a great job at the open source driver for the seemingly pretty limited hardware. Still I guess if you want good Linux support, avoid Broadcom, prefer Intel or other Linux-friendly hardware manufaturers.
Subscribe to:
Posts (Atom)