On 14 October 2010 19:29, Gonzalo Odiard <gonz...@laptop.org> wrote: > I don't see Gnome doing anything with this event. > It's a very specific XO thing ...
Oops. I meant to suggest that you look at how GNOME deals with the lid-closed switch. Since, from the kernel point of view, its exactly the same reporting mechanism (through an input device). Whatever interface GNOME is using to listen for lid closes, its very likely that you can listen for ebook mode the same way. > I probably don't are explaining well what I need. > I am reading the event with dbus, it's working. I think it's the wright way > to do this today. > But it's strange it send a array with two boolean values (lid and ebook > switchs) but ever with the value in False. Are you sure those 2 values are supposed to refer to the lid and ebook switches? > I want to check if the software who emit the dbus signal is checking in the > wright place for the switch state. Then you need to look closely at HAL, if you're tracking down that HAL message. I don't know anyone in the OLPC community who has instant expertise here; you need to dive into the docs and code and figure it out. > Also the devices are different: > in XO-1 cat /proc/bus/input/devices show the lid switch in event1 ant the > ebook switch in event2 > in XO-1.5 cat /proc/bus/input/devices show the lid switch in event2 ant the > ebook switch in event4 > in the XO-1 don't have the /proc/acpi directory That's to be expected, the XO-1 doesn't use ACPI and the XO-1.5 does. But the aim is of course for the events to appear similar enough that you don't have to care at the activity level. There may well be kernel issues to solve here. Daniel _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel