[Kde-hardware-devel] KDE (Linux hardware) issues

[Eric Gaumer]

On Sunday 08 January 2006 2:26 pm, Alexander Antoniades wrote:
> My biggest frustration with Linux is the complex nature of its various
> hardware interfaces and how hard it can be to figure out where
> problems are and how to resolve them. From what I've seen, on one
> level, Linux is very much like Windows9x in its structure, I know it's
> much different, in most but bare with me. :)

Actually I would say it's quite opposite. It's much easier to locate problems 
on Linux than on Windows.

I understand your point though and to most average users, they see Windows as 
being much easier. The trick is to provide the average user with the same 
abilities that Windows offers to setup and install hardware while still 
retaining the flexible nature of Linux as seen from a developers standpoint.

Windows provides a standard ABI which some have argued should be the case in 
Linux. Linus has stated numerous times that there will never be a kernel ABI 
and so we have to design new ways of dealing with these types of issues. In 
the end, the product is much more stable while admittedly more difficult for 
the average user to work with. We don't want to sacrifice stability for ease 
of use though and that philosophy introduces complexities.

You have to consider that Windows doesn't ship with most drivers. If you buy 
some device it comes with drivers that the manufacturer specifically wrote 
for that device and that operating system.

Linux is a different animal. Some vendors offer drivers but not all are open 
sourced and so they taint things. Linux has the responsibility of writing and 
packaging these drivers directly in the kernel.

On one side of things it makes setting up hardware easier because these 
drivers are native to the operating system. On the other hand it's often hard 
to keep up with all the hardware available these days. This is where 
standards become important.

At any rate, it often appears to be simple task from the standpoint of the 
average user. A "Windows does it so why can't Linux" type of outlook. It's 
important to understand that there is a vast difference in the entire Linux 
model. These problems can be addresses but it's not as easy as simply cloning 
Windows behavior. Better hardware detection and support is going to come in 
greatest volume by vendors complying to standards, understanding there is a 
need, and working with kernel developers to produce quality open source 
drivers.

A bit of a digression but I think this is often a thing that most users don't 
understand.

>
> Any help that would at least say where the information that any
> hardware browser is getting would go a long way in making it more
> useful. For example I'm typing this from a laptop with a wireless
> PCMCIA card, but KInfoCenter reports "No PCMCIA controller detected"
> obviously it's working, but something along the lines of
> "/etc/pcmcia.conf reports no devices" or "no supported PCMCIA modules
> in current kernel detected" would be much more helpful.

As of 2.6.14 a new pcmcia infrastructure exists that uses the Utopia stack. 
Utopia is providing a uniform model for dealing with hardware and so user 
space applications now have a centralized means of communication with the 
kernel hardware layer. I think the types of problems you described above are 
quickly becoming a thing of the past.

> This is interesting. For me largely Linux hardware either "just works"
> or doesn't. I can hack some simple configs like xorg and such, but
> kernel modules are a mystery to me if they don't work initially I have
> no clue as to how to resolve anything outside of recompiling the
> kernel. I'm curious to see how linux's hardware handling will
> progress.
>
> For example I have an HP Pavillion ze4500, and by default the PCMCIA
> locks up when used. I was fortunate enough to find an awesome webpage
> http://emeitner.f2o.org/nx9005/ by someone much smarter than me who
> figured out it was due to IRQs being misrouted and a change to
> /etc/pcmcia/config.opts would make it work. Outside of this web page I
> don't know how I would have resolved this problem, especially since
> this problem causes the hardware to lock. I'm curious if any
> initiatives like solid would help resolve problems like this.

What would you describe as the problem though? The fact that the IRQ conflict 
existed, knowing how to change it, or knowing the conflict existed? On 
Windows if this problem existed it would often show up in the device manager. 
You would still have to search on line for a solution. I assume you would 
like to have Linux somehow notify the user that a problem exists. I think 
that's a reasonable request but it may be a little outside the scope of what 
Solid is about. This would involve the kernel passing this information up to 
the applications. That's an addressable problem but again, I don't think it's 
within the scope of this project.

-- 
Eric Gaumer
Debian GNU/Linux PPC
egaumer at pagecache.org
http://egaumer.pagecache.org
PGP/GPG Key 0xF15D41E9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20060109/c6c7bbd7/attachment.pgp