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