sugar shouldn't handle XO keyboard keys directly

[pgf]

it seems to me that as sugar grows to be a more general platform-agnositic system, its direct hooks into the XO infrastructure shoule be weakened. my immediate issue is that my olpc-kbdshim and olpc-powerd packages change the mechanisms by which the screen gets a) rotated and b) brightened/darkened. since sugar handles these respective keyboard commands directly, there's a conflict.

currently olpc-kbdshim and olpc-powerd each apply simple patches to keyhandler.py when they install. i'd like to see sugar modified to make these patches unnecessary -- either by incorporating the attached patch directly, or something similar.

(if there are other plans to separate the sugar shell from platform-specifics like this, please let me know!)

[tomeu]

I think that in modern distros this is taken care by HAL?

[pgf]

so you're suggesting that keyhandler.py shouldn't be involved at all?

does that mean it would never receive those keycodes? or simply that it wouldn't act on them?

[tomeu]

I think that Sugar shouldn't have to care about those keys, as that functionality would be moved to a lower level component like HAL.

[tomeu]

Paul, Martin, what do you think?

[pgf]

recent versions of olpc-kbdshim handle the brightness and rotate keys directly. so, for the XO, sugar no longer needs to be involved for those keys. however, nothing has changed for the volume keys, to my knowledge.

[tomeu]

Replying to pgf:

recent versions of olpc-kbdshim handle the brightness and rotate keys directly. so, for the XO, sugar no longer needs to be involved for those keys. however, nothing has changed for the volume keys, to my knowledge.

Great to hear that, does this patch look good to you? Also, do you know if Sugar still needs to take care of unfreezing the DCON?

[pgf]

yes, that looks about right.

i notice that sugar supports alt-shift-r as a keyboard alias for the rotate key. olpc-kbdshim only supports the "real" brightness key. when is that alias useful on an XO?

as for the DCON -- powerd currently does an unfreeze 10 seconds after it starts, but that's just a hack, and we don't know XO-1.5 will use powerd yet. it does seem like the system (any system) needs an event or signal that tells all interested processes "the system has finished booting, all the way to the user". this will be a problem for other desktops on the XO as well. (another example -- currently powerd may idle-suspend the system while it's still booting. that should be held off until the desktop is displayed, at least.)

[tomeu]

Replying to pgf:

yes, that looks about right.

Thanks, will push it.

i notice that sugar supports alt-shift-r as a keyboard alias for the rotate key. olpc-kbdshim only supports the "real" brightness key. when is that alias useful on an XO?

Not for the XO, was there just for testing that behavior on sugar-emulator.

as for the DCON -- powerd currently does an unfreeze 10 seconds after it starts, but that's just a hack, and we don't know XO-1.5 will use powerd yet. it does seem like the system (any system) needs an event or signal that tells all interested processes "the system has finished booting, all the way to the user". this will be a problem for other desktops on the XO as well. (another example -- currently powerd may idle-suspend the system while it's still booting. that should be held off until the desktop is displayed, at least.)

Ok, will leave that code there for now. When we know that the next Sugar release will run on the XOs without requiring the Ohm call, I will remove it.

About the more generic question of how to signal that the desktop is loaded:

 http://mail.gnome.org/archives/desktop-devel-list/2009-August/msg00064.html

[tomeu]

More will happen in 0.88

[walter]

tomeu: any comment? 0.90?

[pgf]

fyi, the latest versions of kbdshim now handle the brightness, volume, and rotation keys, so sugar doesn't need to handle any of those itself.

[sascha_silbe]

The key handling part has been pushed as  d1944e61be72d2231a4518a88ed2020be4a35a89. Closing ticket since it's only about those.
Please file a new ticket once we can get rid of the unfreeze OHM call as well.