Opened 11 years ago

Closed 6 years ago

#342 closed defect (fixed)

sugar-emulator: some keys (e.g. cursor keys) not working

Reported by: sascha_silbe Owned by: sascha_silbe
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Sugar Version: Git as of bugdate
Severity: Major Keywords:
Cc: bernie Distribution/OS: Unspecified
Bug Status: New

Description

At least in sugar-emulator, the cursor keys are not working inside the address bar in Browse (neither do Ctrl+a, Ctrl+e etc.). I can position the cursor and mark text using a pointer device, but not with the keyboard.

Change History (16)

comment:1 Changed 11 years ago by erikos

  • Bug Status changed from Unconfimed to New
  • Component changed from Browse to sugar-jhbuild
  • Owner changed from erikos to marcopg

That is an Xephyr bug AFAIKT. Can you check whether a bug for the reported issue is already filed? If it has not been filed yet please do so. Also ensure that both bug reports contain a link to each other. Thanks in advance!

comment:2 Changed 11 years ago by sascha_silbe

  • Distribution/OS changed from Ubuntu to Unspecified
  • Severity changed from Minor to Major
  • Summary changed from Browse: cursor not working inside address bar to sugar-emulator: some keys (e.g. cursor keys) not working

You're right, this happens in other activities as well and has been reported upstream as Xephyr bug #19365.
Unfortunately, the mentioned workaround (passing -kb) causes the keyboard not to work at all.

comment:3 Changed 11 years ago by sascha_silbe

In addition to cursor keys not working, it's simulating an _english_ keyboard layout (=> Umlauts not working, punctuation in places I'm not used to and not printed on keyboard, ...). :-/

comment:4 Changed 11 years ago by sascha_silbe

  • Owner changed from marcopg to sascha_silbe
  • Status changed from new to assigned

comment:5 Changed 10 years ago by sascha_silbe

Partial workaround posted on the wiki now:

Note that due to a bug in Xephyr your keyboard might not work as expected. A partial workaround is to run setxkbmap <keymap name> in ~/.sugar/debug (this file will be created on first run of Sugar). Most "regular" keys should work fine after that, some "special keys" (e.g. cursor up/down) might still refuse to operate as intended.

The "keymap name" usually is a two letter country code, e.g. "de" for german or "fr" for french.

comment:6 Changed 10 years ago by erikos

Sascha thanks for posting the workaround.

I have the non working keyboard here on F11 - nearly none of the keys (Home, Alt...) do work without applying the setxkbmap. I guess we need to follow up on the evdev support in order to get it working again http://bugs.freedesktop.org/show_bug.cgi?id=19365

comment:7 follow-up: Changed 10 years ago by DanKrejsa

(Until this is fixed upstream, the following may be relevant)
Hi,

I've found what I think is a better workaround for the Xephyr problem seen
running sugar-emulator, in which keyboard mappings are not inherited from
the main X server.

One workaround known so far is to go into the Terminal activity
and run

setxkbmap us

(or whatever keyboard map & options you want). However, that doesn't fix
all keys, in particular it doesn't fix the arrow keys (at least for me). What does
work is to execute, in a host shell outside of the sugar emulator,

xkbcomp $DISPLAY :100

replacing :100 with the actual X display of the Xephyr X server;
$DISPLAY is of course the name of the encompassing X display in
which Xephyr runs as a client. This copies the XKB settings from
the encompassing display to the display under Xephyr.

You have to run xkbcomp after having sent some keyboard events
to Xephyr -- if you do it before that, it seems not to work for some reason
that I don't understand well.

That leads me to a really hackish patch to:

sugar-jhbuild/source/sugar/bin/sugar-emulator

adding a -k option that does the xkbcomp to copy the XKB settings to
Xephyr before starting sugar. The most awkward bit is that I had to
add code to put an ugly little window in the Xephyr server waiting for an
initial keystroke before calling xkbcomp. I know very little about X; maybe
someone can figure out how to avoid that bit.

If you use the patch, start sugar-emulator as follows:

$ ./sugar-jhbuild run sugar-emulator -k &

Briefly tested only under Fedora 11. Enjoy,

diff --git a/bin/sugar-emulator b/bin/sugar-emulator
index acd5976..dfe2230 100644
--- a/bin/sugar-emulator
+++ b/bin/sugar-emulator
@@ -24,13 +24,43 @@ from optparse import OptionParser
 import gtk
 import gobject
 
+import sys
+
 from sugar import env
 
+class WaitForKey:
+    def destroy(self, widget, data=None):
+        gtk.main_quit()
+
+    def __init__(self, dst_display):
+        display = gtk.gdk.Display(dst_display)
+        screen = display.get_default_screen()
+        window = gtk.Window(gtk.WINDOW_TOPLEVEL)
+        self.window = window
+        self.display = display
+        self.screen = screen
+        window.set_screen(screen)
+        # No window manager yet...
+        window.set_geometry_hints(None, 600, 450)
+        window.connect("destroy", self.destroy)
+        window.connect("key-release-event", self.destroy)
+        vbox = gtk.VBox()
+        entry = gtk.Entry()
+        entry.set_text ("Type a key here!")
+        window.add(vbox)
+        vbox.pack_start(entry, True, True)
+        entry.show()
+        vbox.show()
+        window.show()
+
+    def main(self):
+        gtk.main()
+
 default_dimensions = (800, 600)
-def _run_xephyr(display, dpi, dimensions, fullscreen):
+def _run_xephyr(display, dpi, dimensions, fullscreen, noreset = False):
     cmd = [ 'Xephyr' ]
     cmd.append(':%d' % display)
-    cmd.append('-ac') 
+    cmd.append('-ac')
 
     screen_size = (gtk.gdk.screen_width(), gtk.gdk.screen_height())
 
@@ -57,6 +87,9 @@ def _run_xephyr(display, dpi, dimensions, fullscreen):
         cmd.append('-dpi')
         cmd.append('%d' % dpi)
 
+    if noreset :
+        cmd.append('-noreset')
+
     result = gobject.spawn_async(cmd, flags=gobject.SPAWN_SEARCH_PATH)
     pid = result[0]
 
@@ -69,20 +102,39 @@ def _check_xephyr(display):
                              stderr=open(os.devnull, "w"))
     return result == 0
 
-def _start_xephyr(dpi, dimensions, fullscreen):
+def _copy_xkb(src_display, dst_display):
+    wfk = WaitForKey(dst_display)
+    wfk.main()
+    result = subprocess.call(['xkbcomp', src_display, dst_display])
+    print >> sys.stderr, "'xkbcomp %s %s' returned %d" % \
+           (src_display, dst_display, result)
+
+def _start_xephyr(dpi, dimensions, fullscreen, copy_xkb = False):
+
+    try:
+        old_display = os.environ['DISPLAY']
+    except KeyError:
+        options.copy_xkb = False
+
     # FIXME evil workaround until F10 Xephyr is fixed
     if os.path.exists('/etc/fedora-release'):
         if open('/etc/fedora-release').read().startswith('Fedora release 10'):
-            _run_xephyr(random.randint(100, 500), dpi, dimensions, fullscreen)
+            _run_xephyr(random.randint(100, 500),
+                        dpi, dimensions, fullscreen, copy_xkb)
+            if copy_xkb:
+                time.sleep(1.0)
+                _copy_xkb (old_display, os.environ['DISPLAY'])
             return
 
     for display in range(100, 110):
         if not _check_xephyr(display):
-            _run_xephyr(display, dpi, dimensions, fullscreen)
+            _run_xephyr(display, dpi, dimensions, fullscreen, copy_xkb)
 
             tries = 10
             while tries > 0:
                 if _check_xephyr(display):
+                    if (copy_xkb):
+                        _copy_xkb (old_display, os.environ['DISPLAY'])
                     return
                 else:
                     tries -= 1
@@ -143,11 +195,17 @@ def main():
     parser.add_option('-F', '--no-fullscreen', dest='fullscreen',
                       action='store_false',
                       help='Do not run emulator in fullscreen mode')
+    parser.add_option('-k', '--copy-xkb', dest='copy_xkb',
+                      action='store_true', default=False,
+                      help='Copy XKB settings from X server to Xephyr')
     (options, args) = parser.parse_args()
 
     _setup_env()
 
-    _start_xephyr(options.dpi, options.dimensions, options.fullscreen)
+    _start_xephyr(options.dpi,
+                  options.dimensions,
+                  options.fullscreen,
+                  options.copy_xkb)
 
     if options.scaling:
         os.environ['SUGAR_SCALING'] = options.scaling

comment:8 in reply to: ↑ 7 Changed 10 years ago by garycmartin

Replying to DanKrejsa:

What does work is to execute, in a host shell outside of the sugar emulator,

xkbcomp $DISPLAY :100


replacing :100 with the actual X display of the Xephyr X server;
$DISPLAY is of course the name of the encompassing X display in
which Xephyr runs as a client. This copies the XKB settings from
the encompassing display to the display under Xephyr.

Fab, yes this gets very close to working cursors for me (sugar-jhbuild under F10, under VirtualBox on a Mac). Right, left, and down cursor keys now work. But, the up cursor key is still being grabbed and used for taking screenshots. I wonder if some other component is mapping that to screenshot function (vaguely remember some talk about adding Print Screen as a new screen shot key, maybe clobbering my up cursor)?

comment:9 Changed 10 years ago by DanKrejsa

Hi Gary,
I also saw the Up cursor key being interpreted as PrintScreen, but for me
the 'xkbcomp $DISPLAY :100' command fixed that. Evidently there are variations
among distributions in this regard, even among Fedora distributions.

Tomeu also mentioned that the xkbcomp command was failing (or at least
emitting an ugly warning message) on a Ubuntu Intrepid. So, the xkbcomp
seems not to work in all cases. I guess it's at best another partial workaround.

  • Dan

comment:10 Changed 10 years ago by bernie

  • Cc bernie added

I think this bug was fixed by Sayamindu, setting the evdev keycodes by default.

Can we confirm this?

comment:12 Changed 10 years ago by sascha_silbe

  • Resolution fixed deleted
  • Status changed from closed to reopened

At least out of the box (i.e. without the user invoking any special command) this still happens on Debian Squeeze, so it's not fixed.

comment:13 Changed 10 years ago by sascha_silbe

  • Component changed from sugar-jhbuild to sugar

comment:14 Changed 9 years ago by martin.langhoff

I had this same problem with Xephyr on the XO (on 10.1.2) running a Xephyr for other reasons.

After a bit of research, starting Xephyr with -keybd ephyr,xkbmodel=evdev (instead of -kb or +kb) works well for me. May help sugar-emulator.

It doesn't handle the complete keyboard map for some reason -- ñ for example does not work.

comment:15 Changed 8 years ago by bert

In Fedora 15, the xkbcomp workaround does not work around it anymore.

comment:16 Changed 8 years ago by bert

Found a workaround (again, Fedora 15). Add this to _run_xephyr() in /usr/lib/python2.7/site-packages/jarabe/util/emulator.py:

    cmd += ['-keybd', 'ephyr,,xkbmodel=pc105,xkblayout=us,xkbrules=evdev']

YMMV with a non-US layout.

comment:17 Changed 6 years ago by dnarvaez

  • Resolution set to fixed
  • Status changed from reopened to closed

sugar-emulator is dead, works in sugar-runner afaik

Note: See TracTickets for help on using tickets.