Re: [Sugar-devel] Dbus signal when ebook switch is activated
On Thu, Oct 14, 2010 at 5:35 PM, Paul Fox p...@laptop.org wrote: sascha wrote: Excerpts from Gonzalo Odiard's message of Thu Oct 14 22:09:09 +0200 2010: It's simple and it's explained in http://dev.laptop.org/ticket/10396 At least in Read (and in most if not all activities), the dpad should work the same regardless of whether the keyboard is available (non-ebook mode) or not (ebook mode). Thus there's no reason to query the ebook mode switch in the first place. i suspect the point is that in normal mode it's okay for the focus to be elsewhere, since there's a touchpad with which to change the focus. in ebook mode, that's not the case -- if focus isn't on the text area, then you're stuck, and have to open the laptop to click. Yes, this is the problem. A novice user is confused about why the dpad don't work. Gonzalo paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
Excerpts from Gonzalo Odiard's message of Wed Oct 13 17:33:50 +0200 2010: bus.add_signal_receiver(my_func, dbus_interface=org.freedesktop.Hal.Device, signal_name=PropertyModified) HAL has been deprecated [1] and will not be available anymore at some point in the future, so I advise against relying on it. I don't know what the best way to listen to an ebook switch is. acpid might be worth a look: In addition to rule files, acpid also accepts connections on a UNIX domain socket (/var/run/acpid.socket by default). Any application may connect to this socket. Once connected, acpid will send the text of all ACPI events to the client. The client has the responsibility of filtering for messages about which it cares. acpid will not close the client socket except in the case of a SIGHUP or acpid exiting. Asking for advice on devkit-devel [2] might be a good idea as well. UPower already has a LidIsClosed property (and sends property change notifications [4]) so it might be straightforward to add support for ebook switches. Sascha [1] http://lists.freedesktop.org/archives/hal/2008-May/011560.html [2] http://lists.freedesktop.org/mailman/listinfo/devkit-devel [3] http://upower.freedesktop.org/docs/UPower.html#UPower:LidIsClosed [4] http://upower.freedesktop.org/docs/UPower.html#UPower::Changed -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
On Thu, Oct 14, 2010 at 9:27 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Gonzalo Odiard's message of Wed Oct 13 17:33:50 +0200 2010: bus.add_signal_receiver(my_func, dbus_interface=org.freedesktop.Hal.Device, signal_name=PropertyModified) HAL has been deprecated [1] and will not be available anymore at some point in the future, so I advise against relying on it. I don't know what the best way to listen to an ebook switch is. acpid might be worth a look: Most distros don't use acpid either In addition to rule files, acpid also accepts connections on a UNIX domain socket (/var/run/acpid.socket by default). Any application may connect to this socket. Once connected, acpid will send the text of all ACPI events to the client. The client has the responsibility of filtering for messages about which it cares. acpid will not close the client socket except in the case of a SIGHUP or acpid exiting. Asking for advice on devkit-devel [2] might be a good idea as well. UPower already has a LidIsClosed property (and sends property change notifications [4]) so it might be straightforward to add support for ebook switches. I think this should be an input event, I think in most cases this is how input from lid switches and the like are handled across most things now. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
Thanks Sasha and Peter Anybody know what software is sending the signal now? Gonzalo On Thu, Oct 14, 2010 at 6:38 AM, Peter Robinson pbrobin...@gmail.comwrote: On Thu, Oct 14, 2010 at 9:27 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Gonzalo Odiard's message of Wed Oct 13 17:33:50 +0200 2010: bus.add_signal_receiver(my_func, dbus_interface=org.freedesktop.Hal.Device, signal_name=PropertyModified) HAL has been deprecated [1] and will not be available anymore at some point in the future, so I advise against relying on it. I don't know what the best way to listen to an ebook switch is. acpid might be worth a look: Most distros don't use acpid either In addition to rule files, acpid also accepts connections on a UNIX domain socket (/var/run/acpid.socket by default). Any application may connect to this socket. Once connected, acpid will send the text of all ACPI events to the client. The client has the responsibility of filtering for messages about which it cares. acpid will not close the client socket except in the case of a SIGHUP or acpid exiting. Asking for advice on devkit-devel [2] might be a good idea as well. UPower already has a LidIsClosed property (and sends property change notifications [4]) so it might be straightforward to add support for ebook switches. I think this should be an input event, I think in most cases this is how input from lid switches and the like are handled across most things now. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
gonzalo wrote: Thanks Sasha and Peter Anybody know what software is sending the signal now? /dev/input/event4 on my XO-1.5. paul Gonzalo On Thu, Oct 14, 2010 at 6:38 AM, Peter Robinson pbrobin...@gmail.comwrote: On Thu, Oct 14, 2010 at 9:27 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Gonzalo Odiard's message of Wed Oct 13 17:33:50 +0200 2010: bus.add_signal_receiver(my_func, dbus_interface=org.freedesktop.Hal.Device, signal_name=PropertyModified) HAL has been deprecated [1] and will not be available anymore at some point in the future, so I advise against relying on it. I don't know what the best way to listen to an ebook switch is. acpid might be worth a look: Most distros don't use acpid either In addition to rule files, acpid also accepts connections on a UNIX domain socket (/var/run/acpid.socket by default). Any application may connect to this socket. Once connected, acpid will send the text of all ACPI events to the client. The client has the responsibility of filtering for messages about which it cares. acpid will not close the client socket except in the case of a SIGHUP or acpid exiting. Asking for advice on devkit-devel [2] might be a good idea as well. UPower already has a LidIsClosed property (and sends property change notifications [4]) so it might be straightforward to add support for ebook switches. I think this should be an input event, I think in most cases this is how input from lid switches and the like are handled across most things now. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel part 2 text/plain 153 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
On 14 October 2010 10:38, Peter Robinson pbrobin...@gmail.com wrote: I think this should be an input event, I think in most cases this is how input from lid switches and the like are handled across most things now. It already is an input event, but I suspect that diving down into opening input devices is the wrong thing to do. Next sensible step would be to look at how GNOME does it. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
On Thu, Oct 14, 2010 at 4:59 PM, Daniel Drake d...@laptop.org wrote: On 14 October 2010 10:38, Peter Robinson pbrobin...@gmail.com wrote: I think this should be an input event, I think in most cases this is how input from lid switches and the like are handled across most things now. It already is an input event, but I suspect that diving down into opening input devices is the wrong thing to do. Next sensible step would be to look at how GNOME does it. If its an input event it can then surely be dealt with like any other special key within X or gnome. I presume its the rotate button bottom right hand corner of the screen. I think there's an X button for rotate on table computers, could it be mapped to that as its similar functionality and would then also work on tablet computers as well. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
peter wrote: On Thu, Oct 14, 2010 at 4:59 PM, Daniel Drake d...@laptop.org wrote: On 14 October 2010 10:38, Peter Robinson pbrobin...@gmail.com wrote: I think this should be an input event, I think in most cases this is how input from lid switches and the like are handled across most things now. It already is an input event, but I suspect that diving down into opening input devices is the wrong thing to do. Next sensible step would be to look at how GNOME does it. If its an input event it can then surely be dealt with like any other special key within X or gnome. I presume its the rotate button bottom right hand corner of the screen. I think there's an X button for rotate on table computers, could it be mapped to that as its similar functionality and would then also work on tablet computers as well. the rotate key is already handled as a special key. we're talking about the ebook switch, which is an open or closed magnetic sensor that can tell you when the screen is fully folded into the ebook position. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
Excerpts from Daniel Drake's message of Thu Oct 14 17:59:24 +0200 2010: [ebook switch] It already is an input event, but I suspect that diving down into opening input devices is the wrong thing to do. Next sensible step would be to look at how GNOME does it. Does Gnome support ebook switches at all? If so, where? I.e. what part of the system resp. what application changes behaviour based on the ebook switch? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
I don't see Gnome doing anything with this event. It's a very specific XO thing ... 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. I want to check if the software who emit the dbus signal is checking in the wright place for the switch state. Now I am testing in a XO-1, and don't have the dbus signal. 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 The two machines have a 852 img Gonzalo On Thu, Oct 14, 2010 at 12:59 PM, Daniel Drake d...@laptop.org wrote: On 14 October 2010 10:38, Peter Robinson pbrobin...@gmail.com wrote: I think this should be an input event, I think in most cases this is how input from lid switches and the like are handled across most things now. It already is an input event, but I suspect that diving down into opening input devices is the wrong thing to do. Next sensible step would be to look at how GNOME does it. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
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
Re: [Sugar-devel] Dbus signal when ebook switch is activated
On Thu, Oct 14, 2010 at 4:20 PM, Daniel Drake d...@laptop.org wrote: 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? No. 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. Thanks. Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
Excerpts from Gonzalo Odiard's message of Thu Oct 14 20:29:30 +0200 2010: [ebook switch] It's a very specific XO thing ... It isn't, but at least until recently it was rather unusual for devices capable of running Gnome. I probably don't are explaining well what I need. Looks like it. What I am missing is some background information: What do you want to achieve? Which components do you intend to modify? Which systems (distro version etc.) do you target? I am reading the event with dbus, it's working. I think it's the wright way to do this today. As you have shown yourself, it isn't working as you're getting incorrect values. Whether trying to fix an obsolete piece of software is really the right thing to do will depend on the answers to the questions above. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
On Thu, Oct 14, 2010 at 4:43 PM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Gonzalo Odiard's message of Thu Oct 14 20:29:30 +0200 2010: [ebook switch] It's a very specific XO thing ... It isn't, but at least until recently it was rather unusual for devices capable of running Gnome. I probably don't are explaining well what I need. Looks like it. What I am missing is some background information: What do you want to achieve? It's simple and it's explained in http://dev.laptop.org/ticket/10396 If you use the Read activity and put your XO in ebook position, if the focus is in any other widget than the viewer, you can't navigate using the dpad. One first approach suggested by Simon was put the focus in the viewer when the activity start. The another change I am proposing is catch the ebook switch event and put the focus in the viewer. The proposed patch works, but I need to read the switch state after the event is catched. I don't know if there are a better way. Which components do you intend to modify? The Read activity. Which systems (distro version etc.) do you target? Sugar 0.84 and 0.90 in XO-1.5 I am reading the event with dbus, it's working. I think it's the wright way to do this today. As you have shown yourself, it isn't working as you're getting incorrect values. Whether trying to fix an obsolete piece of software is really the right thing to do will depend on the answers to the questions above. Yes. I agree. Gonzalo Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
Excerpts from Gonzalo Odiard's message of Thu Oct 14 22:09:09 +0200 2010: It's simple and it's explained in http://dev.laptop.org/ticket/10396 At least in Read (and in most if not all activities), the dpad should work the same regardless of whether the keyboard is available (non-ebook mode) or not (ebook mode). Thus there's no reason to query the ebook mode switch in the first place. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
sascha wrote: Excerpts from Gonzalo Odiard's message of Thu Oct 14 22:09:09 +0200 2010: It's simple and it's explained in http://dev.laptop.org/ticket/10396 At least in Read (and in most if not all activities), the dpad should work the same regardless of whether the keyboard is available (non-ebook mode) or not (ebook mode). Thus there's no reason to query the ebook mode switch in the first place. i suspect the point is that in normal mode it's okay for the focus to be elsewhere, since there's a touchpad with which to change the focus. in ebook mode, that's not the case -- if focus isn't on the text area, then you're stuck, and have to open the laptop to click. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Dbus signal when ebook switch is activated
I am trying to catch a event when the ebook switch in a XO-1.5 is activated
and read the switch state.
Using dbus-monitor I have found the signal emited, but the message does not
inform the switch state. It 's odd because send a array of booleans values,
but are always in False.
The signal is emited when the ebook switch or the lid switch are activated.
Simple test code:
[o...@xo-a7-2b-49 ~]$ cat test-dbus.py
#!/usr/bin/env python
#def my_func(account, sender, message, conversation, flags):
def my_func(sender, message):
print sender, said:, message
import dbus, gobject
from dbus.mainloop.glib import DBusGMainLoop
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus()
bus.add_signal_receiver(my_func,
dbus_interface=org.freedesktop.Hal.Device,
signal_name=PropertyModified)
loop = gobject.MainLoop()
loop.run()
I see this when activate the switchs:
[o...@xo-a7-2b-49 ~]$ python test-dbus.py
1 said: dbus.Array([dbus.Struct((dbus.String(u'button.state.value'),
dbus.Boolean(False), dbus.Boolean(False)), signature=None)],
signature=dbus.Signature('(sbb)'))
I know I can read the switch state from
/proc/acpi/olpc-switch/ebook/EBK/state and /proc/acpi/button/lid/LID/state
The question is: the dbus message must send the state? i am doing anything
wrong?
Finally, there are a similar procedure to the XO-1?
I am doing all this to http://dev.laptop.org/ticket/10396
Thanks
Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
