macosx(carbon): slow keyboard responsiveness bug fix

macosx(carbon): slow keyboard responsiveness bug fix

[William Xu]

Latest cvs trunk works on macosx again, finally ! 

This bug is introduced in: 

,----[ src/macterm.c ]
| Revision 1.237 - (view) (download) (as text) (annotate) - [select for diffs]
| Thu Oct 25 02:38:38 2007 UTC (3 weeks, 4 days ago) by monnier
| Branch: MAIN
| CVS Tags: lexbind-base
| Changes since 1.236: +20 -0 lines
| Diff to previous 1.236
| 
| Make `window-system' into a keyboard-local variable (rather than
| frame-local as done originally by multi-tty).
| 
| * startup.el (window-system): Remove.  Don't make it frame-local.
| 
| * keyboard.h (struct kboard): Add Vwindow_system.
| * keyboard.c (init_kboard): Set a default for Vwindow_system.
| (mark_kboards): Mark Vwindow_system.
| 
| * dispnew.c (syms_of_display) <window-system>: Declare terminal-local.
| (init_display): Don't set the obsolete `window-system' frame-param.
| 
| * xterm.c (x_term_init):
| * w32term.c (w32_create_terminal):
| * term.c (init_tty): Set Vwindow_system.
| * macterm.c (mac_create_terminal): Set a keyboard (missing piece of the
| multi-tty merge maybe?), copied from w32term.c.  Set Vwindow_system.
| 
| * xfns.c (Fx_create_frame, x_create_tip_frame):
| * w32fns.c (Fx_create_frame, x_create_tip_frame):
| * macfns.c (Fx_create_frame):
| Don't set the obsolete `window-system' frame-param.
| 
| * frame.h (Qwindow_system): Remove.
| * frame.c (Qwindow_system): Remove.  In `syms_of_frame' as well.
| (Fmake_terminal_frame): Don't set obsolete `window-system' frame-param.
`----

After window-system is changed from frame-local to terminal-local
variable, since macosx doesn't support MULTI_KBOARD, it looks like the
window-system misses a chance to be properly set.(leaving it as t by
default) I doubt other platforms that not yet support MULTI_KBOARD could
have a similar problem.

Index: src/macterm.c
===================================================================
RCS file: /sources/emacs/emacs/src/macterm.c,v
retrieving revision 1.238
diff -u -r1.238 macterm.c
--- src/macterm.c	1 Nov 2007 03:46:14 -0000	1.238
+++ src/macterm.c	19 Nov 2007 10:28:13 -0000
@@ -12772,7 +12772,7 @@
 mac_create_terminal (struct mac_display_info *dpyinfo)
 {
   struct terminal *terminal;
-  
+
   terminal = create_terminal ();
 
   terminal->type = output_mac;
@@ -12838,6 +12838,9 @@
   if (current_kboard == initial_kboard)
     current_kboard = terminal->kboard;
   terminal->kboard->reference_count++;
+#else
+  KBOARD *kbp = &the_only_kboard;
+  kbp->Vwindow_system = intern ("mac");
 #endif
 
   return terminal;

-- 
William

http://williamxu.net9.org

Re: macosx(carbon): slow keyboard responsiveness bug fix

[Stefan Monnier]

> After window-system is changed from frame-local to terminal-local
> variable, since macosx doesn't support MULTI_KBOARD, it looks like the
> window-system misses a chance to be properly set.(leaving it as t by

Could you try and arange for the Mac OS X to work with MULTI_KBOARD?
It shouldn't be difficult (because even though the generic Emacs code
then supports multiple keyboards, the Mac OS X part of the code can
still choose to only create a single keyboard and work the same as
before).


        Stefan

Re: macosx(carbon): slow keyboard responsiveness bug fix

[William Xu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Could you try and arange for the Mac OS X to work with MULTI_KBOARD?
> It shouldn't be difficult (because even though the generic Emacs code
> then supports multiple keyboards, the Mac OS X part of the code can
> still choose to only create a single keyboard and work the same as
> before).

Hmm, it turns out easy. Just enable it, then works fairly well. :P 

Well, there's one problem. Some special keys become undefined, like tab,
return, esc. Do you have an idea what might cause this? The following is
a workaround for this: 

,----
| (global-set-key (kbd "<return>") (kbd "RET"))
| (global-set-key (kbd "<tab>") (kbd "TAB"))
`----

The patch: 

Index: darwin.h
===================================================================
RCS file: /sources/emacs/emacs/src/s/darwin.h,v
retrieving revision 1.32
diff -u -r1.32 darwin.h
--- darwin.h	11 Sep 2007 01:04:00 -0000	1.32
+++ darwin.h	20 Nov 2007 14:58:52 -0000
@@ -52,10 +52,6 @@
 #define MAC_OS
 /* We need a little extra space, see ../../lisp/loadup.el. */
 #define SYSTEM_PURESIZE_EXTRA 30000
-
-/* XXX The MULTI_KBOARD support does not work yet on this platform. */
-#undef MULTI_KBOARD
-
 #endif
 #endif

-- 
William

http://williamxu.net9.org

Re: macosx(carbon): slow keyboard responsiveness bug fix

[Andreas Schwab]

William Xu <william.xwl@gmail.com> writes:

> Well, there's one problem. Some special keys become undefined, like tab,
> return, esc. Do you have an idea what might cause this? The following is
> a workaround for this: 
>
> ,----
> | (global-set-key (kbd "<return>") (kbd "RET"))
> | (global-set-key (kbd "<tab>") (kbd "TAB"))
> `----

Theses keys should actually be defined in local-function-key-map.
Apparently keyboard specific variables are not yet working correctly.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: macosx(carbon): slow keyboard responsiveness bug fix

[Stefan Monnier]

>> Could you try and arange for the Mac OS X to work with MULTI_KBOARD?
>> It shouldn't be difficult (because even though the generic Emacs code
>> then supports multiple keyboards, the Mac OS X part of the code can
>> still choose to only create a single keyboard and work the same as
>> before).

> Hmm, it turns out easy. Just enable it, then works fairly well. :P 

I didn't dare to suggest that it might work ;-)

> Well, there's one problem. Some special keys become undefined, like tab,
> return, esc. Do you have an idea what might cause this? The following is
> a workaround for this: 

> ,----
> | (global-set-key (kbd "<return>") (kbd "RET"))
> | (global-set-key (kbd "<tab>") (kbd "TAB"))
> `----

These should be set up in function-key-map (or local-function-key-map).
I think the problem might be that mac-win.el sets them up in
local-function-key-map directly from the file's top-level whereas it
should probably do it from the mac-initialize-window-system function.

Take a look at how x-win.el does it: it defines a x-alternatives-map and
then activates it in x-initialize-window-system.  mac-win.el should do
the same (search for "[return]" in both files to see where/how the
binding is created).


        Stefan

Re: macosx(carbon): slow keyboard responsiveness bug fix

[CHENG Gao]

*On Mon, 19 Nov 2007 19:38:44 +0900
* Also sprach William Xu <william.xwl@gmail.com>:

> Latest cvs trunk works on macosx again, finally ! 
[...]
> After window-system is changed from frame-local to terminal-local
> variable, since macosx doesn't support MULTI_KBOARD, it looks like the
> window-system misses a chance to be properly set.(leaving it as t by
> default) I doubt other platforms that not yet support MULTI_KBOARD could
> have a similar problem.
>
> Index: src/macterm.c
> ===================================================================
> RCS file: /sources/emacs/emacs/src/macterm.c,v
> retrieving revision 1.238
> diff -u -r1.238 macterm.c
> --- src/macterm.c	1 Nov 2007 03:46:14 -0000	1.238
> +++ src/macterm.c	19 Nov 2007 10:28:13 -0000
> @@ -12772,7 +12772,7 @@
>  mac_create_terminal (struct mac_display_info *dpyinfo)
>  {
>    struct terminal *terminal;
> -  
> +
>    terminal = create_terminal ();
>  
>    terminal->type = output_mac;
> @@ -12838,6 +12838,9 @@
>    if (current_kboard == initial_kboard)
>      current_kboard = terminal->kboard;
>    terminal->kboard->reference_count++;
> +#else
> +  KBOARD *kbp = &the_only_kboard;
> +  kbp->Vwindow_system = intern ("mac");
>  #endif
>  
>    return terminal;

I applied your patch (as mentioned above), and reverted
mac_unicode_keystroke_event in macterm.c to previously correct version,
and edited frame.c as below:
,----
| #ifdef USE_FONT_BACKEND
|   /* Give chance to each font driver to free a frame specific data.  */
|   font_update_drivers (f, Qnil);
| #endif	/* USE_FONT_BACKEND */
`----

then 
./configure --enable-carbon-app
export LIBS=-lresolv (to solve Undefined symbols: _res_init_9)
make bootstrap

I got a successful build of emacs-unicode-2 branch (latest cvs), but
key.mouse respond is still slow and unusable.

But I DO FEEL it's not slow as before. Just still unusably slow.

You said this solved the problem for TRUNK. I just wonder why it does
not work for unicode-2 branch. I read discussions about this problem,
and seems the conclusion is the problem is the same for TRUNK and
unicode-2 branch. (same reason, and I suppose same solution.)


-- 
Ubi bene, ibi patria

Re: macosx(carbon): slow keyboard responsiveness bug fix

[CHENG Gao]

A quick followup to this:

I tried again and added 

,----
|   add_keyboard_wait_descriptor (0);
`----

to mac_term_init (macterm.c) right before

,----
| #if USE_CG_DRAWING
|   mac_init_fringe (terminal->rif);
| #endif
`----


then I did "make" instead of "make bootstrap" (since only macterm.c is
changed).

Now emacs runs different from before.

Though I need wait for several seconds to see what I input, I never see
crazy-running busy mouse. I should say it makes me feel better.

Did I add 
,----
| add_keyboard_wait_descriptor (0);
`----
to wrong place? Or should I add something like
,----
| add_keyboard_wait_descriptor (1 or 99999999999 or some-magic-numero-Dieu-sais-seulement);
`----

Any guru can give me a clue? I feel I am just one step away from a
usable emacs-unicode-2 build under MacOSX. TIA!


-- 
Totus mundus agit histrionem

Re: macosx(carbon): slow keyboard responsiveness bug fix

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > >> Could you try and arange for the Mac OS X to work with MULTI_KBOARD?
  > >> It shouldn't be difficult (because even though the generic Emacs code
  > >> then supports multiple keyboards, the Mac OS X part of the code can
  > >> still choose to only create a single keyboard and work the same as
  > >> before).

I removed the MULTI_KBOARD define, it was set like that by mistake when
I did the initial multi-tty port to Carbon, and nobody has touched it
much since. Given that now the Carbon port warns that it is non
functional, if anybody wants to get this working, it should be done the
right way.

  > > Hmm, it turns out easy. Just enable it, then works fairly well. :P 
  > 
  > I didn't dare to suggest that it might work ;-)
  > 
  > > Well, there's one problem. Some special keys become undefined, like tab,
  > > return, esc. Do you have an idea what might cause this? The following is
  > > a workaround for this: 
  > 
  > > ,----
  > > | (global-set-key (kbd "<return>") (kbd "RET"))
  > > | (global-set-key (kbd "<tab>") (kbd "TAB"))
  > > `----
  > 
  > These should be set up in function-key-map (or local-function-key-map).
  > I think the problem might be that mac-win.el sets them up in
  > local-function-key-map directly from the file's top-level whereas it
  > should probably do it from the mac-initialize-window-system function.

It's not at the top level, it's in x-setup-function-keys. 
It's confusing because the function is not indented. When I did the
initial multi-tty port I didn't want to make unnecessary changes that
would make merging harder. There's more stuff that needs to be properly
indented in the file, but that would make the unicode-2 merge harder.

  > Take a look at how x-win.el does it: it defines a x-alternatives-map and
  > then activates it in x-initialize-window-system.  mac-win.el should do
  > the same (search for "[return]" in both files to see where/how the
  > binding is created).

I changed it to be similar to what w32-win.el does.

None of these is tested, I don't have access to a mac machine.

Re: macosx(carbon): slow keyboard responsiveness bug fix

[Andreas Schwab]

CHENG Gao <chenggao@gmail.com> writes:

> export LIBS=-lresolv (to solve Undefined symbols: _res_init_9)

That should not be necessary any more.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: macosx(carbon): slow keyboard responsiveness bug fix

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 21 Nov 2007 00:32:20 +0100, Andreas Schwab <schwab@suse.de> said:

> CHENG Gao <chenggao@gmail.com> writes:
>> export LIBS=-lresolv (to solve Undefined symbols: _res_init_9)

> That should not be necessary any more.

But, as I said before, neither calling res_init or linking libresolv
is meaningful/necessary on Mac OS X/Darwin because the actual DNS
resolution is performed outside the Emacs process.

  http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01254.html

I don't think it is the right thing to add -lresolv without
considering the meaning/necessity of res_init just to superficially
avoid the link error.

Is Mac OS X/Darwin the only such system?  If so, I would rather add
#undef HAVE_RES_INIT and #undef HAVE_LIBRESOLV in src/s/darwin.h.
Otherwise, it might be better to introduce a new macro such as
RESOLVER_EXTERNAL that disables the effect of HAVE_RES_INIT and
HAVE_LIBRESOLV.

				     YAMAMOTO Mitsuhatu
				mituharu@math.s.chiba-u.ac.jp

Re: macosx(carbon): slow keyboard responsiveness bug fix

[CHENG Gao]

*On Wed, 21 Nov 2007 00:32:20 +0100
* Also sprach Andreas Schwab <schwab@suse.de>:

> CHENG Gao <chenggao@gmail.com> writes:
>
>> export LIBS=-lresolv (to solve Undefined symbols: _res_init_9)
>
> That should not be necessary any more.
>
> Andreas.
Thanks for your info. I'll try again tonight.

-- 
The truth which makes men free is for the most part the truth which men prefer not to hear.

Re: macosx(carbon): slow keyboard responsiveness bug fix

[CHENG Gao]

*On Wed, 21 Nov 2007 09:38:19 +0900
* Also sprach YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

> But, as I said before, neither calling res_init or linking libresolv
> is meaningful/necessary on Mac OS X/Darwin because the actual DNS
> resolution is performed outside the Emacs process.
>
>   http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01254.html
>
> I don't think it is the right thing to add -lresolv without
> considering the meaning/necessity of res_init just to superficially
> avoid the link error.
>
> Is Mac OS X/Darwin the only such system? If so, I would rather add
> #undef HAVE_RES_INIT and #undef HAVE_LIBRESOLV in src/s/darwin.h.
> Otherwise, it might be better to introduce a new macro such as
> RESOLVER_EXTERNAL that disables the effect of HAVE_RES_INIT and
> HAVE_LIBRESOLV.

Thanks for your explanation. I have no idea about dns resolution on
MacOSX. It's just a working workaround I got thru googling. 

-- 
The enemies of Freedom do not argue; they shout and they shoot.

Re: macosx(carbon): slow keyboard responsiveness bug fix

[William Xu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> But, as I said before, neither calling res_init or linking libresolv
> is meaningful/necessary on Mac OS X/Darwin because the actual DNS
> resolution is performed outside the Emacs process.
>
>   http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01254.html

Yes, i can confirm this. I have commented res_init callings, and never
had a DNS resolving problem. 

-- 
William

http://williamxu.net9.org

Re: macosx(carbon): slow keyboard responsiveness bug fix

[William Xu]

CHENG Gao <chenggao@gmail.com> writes:

> You said this solved the problem for TRUNK. 

Yes. It's definitely usable(I'm using it for daily work), although not
as fast as 22.1(but that's why it is called the TRUNK).

> I just wonder why it does
> not work for unicode-2 branch. I read discussions about this problem,
> and seems the conclusion is the problem is the same for TRUNK and
> unicode-2 branch. (same reason, and I suppose same solution.)

I have not yet built unicode-2 branch on macosx. So I have no idea of
that at all.

-- 
William

http://williamxu.net9.org

Re: macosx(carbon): slow keyboard responsiveness bug fix

[William Xu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Given that now the Carbon port warns that it is non functional,

It's functional now. Actually ever since i started to build trunk on
macosx in around Sep, it worked fine most of the time, until
20071025. 

> if anybody wants to get this working, it should be done the right way.

No doubt.

> I changed it to be similar to what w32-win.el does.
>
> None of these is tested, I don't have access to a mac machine.

I just managed to bootstrap it. And it did solve the problem. Thanks. :-)

ps. I think the following FIXME could be safely removed now. 

,----[ macterm.c ]
|   /* FIXME: This keyboard setup is 100% untested, just copied from
|      w32_create_terminal in order to set window-system now that it's
|      a keyboard object.  */
`----

pps. Adding the following makes almost no difference here. I'm not sure
whether it's good or bad to add such stuffs. (Give that CHENG Gao was
talking about the unicode-2 branch)

,----
| add_keyboard_wait_descriptor (0);
`----

-- 
William

http://williamxu.net9.org