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

Alexander Antoniades sanderant at gmail.com
Sun Jan 8 23:26:31 CET 2006


Thanks for taking the time to reply
On 1/8/06, Christopher Blauvelt <cblauvelt at gmail.com> wrote:
> It seems that the first priority of solid should be informational.  The
> device manager that you're describing would be better suited as a "helper
> application."  Or a front end that is capable of accessing the knowledge
> base and downloading and/or compiling drivers as needed.  This would be in
> keeping with the tried and true *nix mantra of do one thing really well.  A
> device manager would be an appropriate application to be released with
> kde4.  It all depends on how ambitious we're willing to be.

I'm assuming Hardware Browser will be something like HAL Device
Manager/KInfoCenter, I'm just arguing that it should be able to assist
in resolving hardware problems. Some help at least in figuring out
where the driver is coming from would be a start.

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. :)

In both there is a kernel/base level that understands certain
hardware, and a monolithic GUI that understands other parts and in
some cases supersedes (or ignores) the settings of the original system
once it's launched.

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.

The laundry list of motherboard components and items like "math
coprocessor" are neat in screenshots, but as a practical matter are
useless since these devices will never fail independent of the larger
system and even if they do there little anyone can do to fix them.

> I don't really understand what you're getting at in your third point.
> Transferring hard drives to another system?

I apologize for being unclear. I was just wondering if there was a way
to query a kernel to see what modules are available and what hardware
they would support. This would be useful in scenarios where you have a
PC with a broken component and want to replace it with another to see
if a new Kernel is in order or not.

> A live CD needs to be a future goal of the project.  I, however, see a very
> limited use for it.  Most of what the knowledge base is all about is what
> driver combination to use to get a device working "as advertised."  That
> takes trial and error and usually some google'ing.  Most of my time spend
> getting devices to work is not spent coding.  In fact, I don't believe my
> coding knowledge really helps me at all.

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.

> Judging by the pace of previous KDE system development I feel that having
> narrowly focused goals and sticking to them will make the biggest
> contribution to KDE and foster the greatest amount of adoption.
> Well that's what I think.  Feel free to disagree.

I agree and KDE's focus on getting things done is why I use it as
opposed to super ambitious projects that are perpetually in beta. I'm
sure whatever you come up with will be a step up, and I hope some of
the distribution vendors help out since this is a clear difficiency
that keeps me from advocating Linux more.

One other note and that would be to solicit other KDE related projects
like KSynaptics and (very importantly for me) Lineak.

Thanks,

Sander


More information about the Kde-hardware-devel mailing list