Alan McKinnon wrote: > On Saturday 16 May 2009 19:14:17 pk wrote: > >> Alan McKinnon wrote: >> >>> I'm not sure who's criticizing DeviceKit, but it isn't me :-) >>> >> I guess it was me... :-) >> >> I find this thread interesting: >> http://lists.freedesktop.org/archives/xorg/2009-May/045561.html >> >> ...especially this: >> http://lists.freedesktop.org/archives/xorg/2009-May/045574.html >> >> Which seems like a much more sane way... to me. I don't know what BSD >> and other platforms use (instead of Udev) but I'm sure one could come up >> with a common API. >> > > Sometimes you have to make several horrendous errors to know what to not do > and thereby deduce what you should do - the only version 3 rule of thumb :-) > > From threads involving the hal maintainers I get the idea that the problem is > not so much the idea of hal, but rather it's implementation. And then there's > those fdi files... > > As I see it, at the bottom of the stack you have a kernel and at the top a > user space app (the X server will do for an example). Plug in a USB device > that the app can use, and the kernel needs to make a node in /dev for it if > it's not already there. The kernel should not be interrogating the device for > all possible info - that is expensive - and doesn't need to. It only needs > enough info to know what driver, major and minor numbers to use. X OTOH, can > successfully use much more info. If you have a 19 button mouse, it would like > to know and could even use it as a one-handed keyboard (extreme example). So > the current model uses udev as the interface to the kernel's nodes and HAL as > the interface to exactly what hardware you have. Seems pretty sane for the > most usual use case. At some point in the stack you will need the > OS-dependant > part, my guess is the best place is between hal and udev. Only Linux uses > udev, but all OSes use something in that spot. And if not, they have static > nodes. > > Meanwhile we have an acknowledged problem with hal - it's too complex, too > many things have been shoved into it that were never catered for in the > design, configuration is horrific - and the devs are having their usual > spirited debate about how best to approach a solution. This is perfectly > normal and perfectly healthy > >
I hope someone wins the debate soon and gets this to work and be "user friendly". I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. If it don't work this time, this could end up a with permanent -hal for xorg-server. I quite happy with the way my box works now anyway. ;-) Just trying to keep up with the times I guess. < Dale crosses fingers and toes to > Dale :-) :-)
