If it's exclusive, why would we choose one or the other? It seems to me(from my very cursory understanding) is that HAL is a more complete solution, and further implemented in the desktop/laptop world. Since that's the case, HAL seems like it'd be easier to port to a palmtop device.
Is freesmartphone.org mentoring for GSoC? If so, perhaps that'd be a better organization for this sort of thing?
-- Jacob Thebault-Spieker Cell: (207) 717-5114 Stanislav Brabec wrote:
Michael 'Mickey' Lauer wrote:On Wednesday 05 March 2008 19:28:57 Stanislav Brabec wrote:Now this is something that grabs my attention. A plugin-based device daemon is something I think could make a nice project. We started brainstorming this @ freesmartphone.org and it's going to happen eventually this year anyways, but I would be glad if someone beat me to it.It needs general discussion before starting to implement: - Should it be based on hal? And should be hal the technology for OE to go? If yes: - Should OE use upstream hal? - Should OE use cut-down hal version? - Should OE use uHAL (micro hal), small and device specific daemon providing device independent interface? - Should it duplicate design of NetworkManager (only one network active in one moment)? - If no: - Should it use script based ifup/ifdown? - Should it use D-Bus to notify users about change? - How to solve huge overkill of any actions (fork, [unswap,] start shell interpreter, start binary, change setup) There are several tools, which try to do the same, but none of them is really usable on PDA:freesmartphone.org would be a really useful standard. Do you think, that the result will become HAL addon or a separate D-Bus daemon? I am thinking about new design of zaurusd and noticed D-Bus as very useful as well, and I am still not decided, whether it would be better as HAL addon or a separate D-Bus daemon. Zaurusd (daemon, which monitors input events and handles status of the lid, headphones and remote) may become a very simple model example. It has only ~100 lines of code, but it demonstrates many issues: Current implementation of zaurusd: 1. zaurusd gets input event 2. zaurusd calls shell interpreter to handle the signal 3. Because zaurusd did not provide the old value, shell script must remember it in a file 4. Scripts are running as root, changes needs to use actual user UID 5. Special assumptions are done to guess, which X session needs rotation 5. Ugly sed filters are used to change ALSA mixer setting 6. There is no way to set-up correct initial state. New implementation should do it in completely different way: - Signals sent by input device are device specific. - One input device provides signals for two different purposes: * headphones handling * screen rotation - The implementation must provide not only signals, but also query for the initial state. - Signals sent by D-Bus should be device independent. - User space handling should be device independent as much as possible: * set headphone mode Auto, Jack On/Off, Speaker On/Off * set jack mode to In/Out/Mic/Headset (knowing what is actually supported by the device) * Rotation 0/1/2/3/Auto (knowing what the driver actually supports) - Action needs to reach different devices: * ALSA for audio * XRandR for rotation Few months ago I wrote D-Bus glue for possible successor of zaurusd, but not yet finished the rest. Then I started to think about HAL addon.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
