GNOME Bugzilla – Bug 558586
handling of keyboard under darwin (quartz)
Last modified: 2008-11-12 12:57:01 UTC
Please describe the problem: As discussed on gtk-devel-list, The current code in gdk/quartz/gdkkeys-quartz.c uses a deprecated (since 10.5) API to handle keyboard layout on darwin, which is not available to x86-64 applications. Here is an initial patch that uses the new TIS API. A better patch would probably be to conditionalize the old code and keep support for 10.4 this way. Steps to reproduce: Building Gtk+ with quartz on 10.5 with x86-64 (gcc -m64) will exhibit the crash whenever you hit a key. Actual results: crash Expected results: key insert :-) Does this happen every time? yes on x86-64 darwin Other information: I'll file the patch as an attachmenet as soon as I get the number
Created attachment 121687 [details] [review] patch against 2.12.11 patch against 2.12.11. Can probably be applied out of the box on 2.14, let me know if not.
If someone wants to work on getting this in, the plan is to use something like #if MAC_OS_X_VERSION_MAX_ALLOWED > MAC_OS_X_VERSION_10_4 new code... # else old code... #endif
Created attachment 121858 [details] [review] new patch against trunk Here is a new patch against svn trunk, with support for older mac os versions based on the macro you suggested. Let me know if you need anything else. Arno
It looks ok, thanks! Have you tried on 10.4 (or using -mmacosx-version-min=10.4 or so)? I assume you have been able to build everything up to gtk+ with -arch x86_64? I'm a bit surprised because there are other things that should have issues (pango and glib for example).
I haven't tried with -mmacosx-version-min=10.4, if you or someone else could try that'd be great, otherwise I can give it a try (I just have too many things to do at the moment!). I could build everything with x86-64 with the following versions: glib-2.18.2 atk-1.24.0 cairo-1.8.0 pango-1.22.2 gtk+-2.12.11 pixman-0.12.0 and I'm working on upgrading to Gtk+ 2.14.4 and cairo 1.8.2 very soon now. I had no particular troubles with glib 2.18.2 nor pango 1.22.2 (although we do have some tricks, see below). I did have a trouble with cairo 1.8.0 because cairo-quartz-font.c references FMGetATSFontRefFromFont which is not defined on my system, so I had to add the right definition. Things are tricky though, and we have a quite complex build script for Gtk+ that we've refined for all the platforms we build Gtk+ for (which includes windows, solaris, linux, darwin, and in the past hpux, tru64, irix), that's quite a challenge... Anyway, there are some strange issues on darwin, in particular wrt to setting (or not) DYLD_LIBRARY_PATH. We also need to patch libtool a little, make use of some LDFLAGS on some modules (such as -no-undefined -bind_at_load). Getting libiconv to build and using the newly built version instead of the system version is also quite a challenge... Arno
I can try to build against 10.4, don't worry about that. The issues I've run into are libjpeg (and some other modules) ends up as 32 bit no matter what I do, glib fails with this: var/folders/zt/ztNMqFM6H58gwwmtvGN9Ok+++TI/-Tmp-//ccRMj5p8.s:814:Incorrect register `%rdx' used with `l' suffix Pango should fail since it uses ATSU(I) which is not supposed to be available in 64-bit, GTK+ uses some more APIs that are not supposed to be in 64-bit.
Committed to trunk, and tested with 10.4. Thanks again!
Great, thanks! We will see if we run into other 64 bits issues, although we haven't encountered issues with pango/atsui so far, which is surprising. Arno
GTK+ still crashes here. I'm on 10.5.5 on a white Macbook, all updates applied, built GTK+ from trunk with jhbuild yesterday (checked the patched file, changes are there). All GTK+ programs I've tried aborts with the following messages: Gdk-ERROR **: cannot get keyboard layout data aborting... Trace/BPT trap Grepping the Makefiles for "m64" did not reveal a single hit; maybe this is the problem?
(In reply to comment #9) > GTK+ still crashes here. I'm on 10.5.5 on a white Macbook, all updates applied, > built GTK+ from trunk with jhbuild yesterday (checked the patched file, changes > are there). Is your issue really related to 64-bit and/or this bug report? The patch here only moves to a new API that exists in the 64-bit frameworks when building on 10.5, i.e. it has nothing to do with fixing 32-bit issues. I think I need some background, like do you get this with unpatched trunk and building with 32-bit, what keyboard layout do you have? > Grepping the Makefiles for "m64" did not reveal a single hit; maybe this is the > problem? No, we are not hardcoding GTK+ to build in 64 bit, that is something the user needs to control (e.g. by setting CFLAGS to "-arch x86_64" or so.
(In reply to comment #10) > Is your issue really related to 64-bit and/or this bug report? The patch here > only moves to a new API that exists in the 64-bit frameworks when building on > 10.5, i.e. it has nothing to do with fixing 32-bit issues. Using GTK+ from SVN, revision 21761 (prior to the patch included on this report being applied), I get no crashes. I've built it by using the default jhbuild settings, so it is being built as 32-bit. > I think I need some background, like do you get this with unpatched trunk and > building with 32-bit, what keyboard layout do you have? I am using a third party keyboard layout ("U.S. International" [1], needed to type in Portuguese using a standard US keyboard). This keyboard layout works OK with GTK+ up to r21761, so I guess it's not the culprit. By the way, I've not tested with a stock keyboard layout and the latest trunk, but I can do so if needed. [1] http://www.brockerhoff.net/usi/
Ah, thanks, that makes it more clear (it was the "still crashes" that consfused me). I'll try to install that layout and see what happens.
OK, doing some investigation, it seems that the new input API in 10.5 doesn't work with non-xml keyboard layouts. Apple is recommending third party layouts to convert to xml using the tool klkchrtoxml which is included in: http://developer.apple.com/textfonts/download/ Maybe you could report this to the author of the layout you are using? In the meantime we can look at adding a fallback using the old deprecated API as long as we're not building in 64-bit.
Reopen until fallback code has been fixed.
Oh, interestingly enough it seems that the latest version of the keylayout already is xml. Could you make sure you have the latest one and test again please? Just to make sure this isn't a different problem.
Created attachment 122328 [details] [review] Another approach This is a bit more strict approach, that only uses the new API when building for 64-bit. Arnaud, maybe you could check if that still works for you? This way we still handle the old layout fallback that needs to old API, when building with 32-bit, keeping away from regressions.
Oh, and it would be great if you could try too, Leandro.
Patch looks reasonable to me. Arno
With the latest trunk (SVN rev. 21775) and the US International keyboard layout version 1.2 (I was with 1.1), GTK+ is working again. I'll try later today with this new patch and the older version.
I've committed the updated patch. Please let me know if you run into more issues.