On Sun, Jan 17, 2021 at 10:01:49AM -0800, Yoshiki Ohshima wrote:
> Thanks everybody for looking into this and I admit that I added confusion.
> 
> One thing, though, is that this round of digging in here was triggered by a report from a group of Japanese users who are making a custom hardware.... I???d like to make sure that the compositioninput case work.
> 

Thanks Yoshiki,

The suggestion that I made to Tim to unset LC_ALL and LC_CTYPE environment
variables will not have any effect on composition input.

However, when I run the VM with -compositioninput and test keystrokes using
the 'f' and 'j' keys, this is what I see:


[502 at 771 keyDown (102) 127659]
[502 at 771 keystroke 'f' (102) 127659]f
[502 at 771 keyDown (106) 127848]
[502 at 771 keystroke 'j' (106) 127848]j
[502 at 771 keyUp (106) 127969]
[502 at 771 keyUp (0) 128233]

It looks to me like key release event for the 'f' key is being delivered
to the image, but it has keycode 0 instead of keycode 102. This does not
look right to me, so I think that the issue with missing key release
event would still be a problem for Japanese users. And it probably is
an existing problem in any Scratch using composition input.

In any case, if a fix for this can be found then we definitely need to
make sure it works for Japanese users and the compositioninput case.

Dave


> 
> 
> -- Yoshiki
> 
> > On Jan 17, 2021, at 8:30 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > ???On Sat, Jan 16, 2021 at 10:15:22PM -0800, tim Rowledge wrote:
> >> 
> >> 
> >>>> On 2021-01-16, at 9:17 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> >>> 
> >>> On Sat, Jan 16, 2021 at 04:03:45PM -0800, tim Rowledge wrote:
> >>>> 
> >>>> 
> >>>>> On 2021-01-16, at 3:33 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> >>>>> . The part I
> >>>>> can't figure out is how it could be working on any of the VMs.
> >>>> 
> >>>> I can't see any case where it can work either but the code is so convoluted you need a native guide. The one thing I can see that might just possibly account for differences is the way that x2sqKey is a function pointer that can end up pointing to any of three routines depending upon assorted commandline options, environment variables and phase of a random selection of Jupiter's moons.
> >>>> 
> >>> 
> >>> Exactly right. Well it's not exactly a function of Jupiter's moons, but
> >>> pretty darn close.
> >>> 
> >>> I've narrowed the issue down some more, and can offer at least a
> >>> workaround for Scratch.
> >>> 
> >>> The reason that the key up events are being lost is that either the
> >>> LC_ALL or the LC_CTYPE environment variable is set. If you unset both of
> >>> these, the key up events will start working.
> >> 
> >> That's interesting. I had tried manually specifying the x2sqKeyPlain by using `-nointl` but it looks like it gets over-ridden pretty quickly. I see that on my Pi 
> >> `
> >> echo $LC_ALL
> >> en_US.UTF-8
> >> `
> > 
> > So we know that there is a problem in the X11 key handling in the VM
> > that is triggered if the environment variable LC_ALL is set. Scratch
> > is now encoountering this problem, whereas previously it had no problem.                
> > 
> > Most likely the thing that has changed is that the Linux environment
> > on Raspberry Pi (updated OS?) is now setting the LC_ALL variable to
> > support locale handling. Apparently Scratch worked fine without this,
> > so the workaround to avoid the problem would be to unset LC_ALL in
> > whatever script is being used to run Scratch.
> > 
> > I don't have a Pi to check, but most likely there is a unix shell
> > script somewhere, such as /usr/bin/scratch, that runs the VM and brings
> > up the Scratch image. If so, then you can add "unset LC_ALL" to the
> > script, and I expect that Scratch will be happy again.
> > 
> > Dave
> > 
> > 
> >> 
> >> So it looks like the big difference is use of XmbLookupString vs XLookupString. Since as mentioned "We can't use XmbLookupString() since that is undefined for key release events." I guess maybe we might try using XLookupString for handling key release events ? It will potentially be wrong for times when a composited character was used but it's really hard to imagine what *wouldn't* be wrong. Maybe one might take comfort in the thought that using a composited character within the sort of Scratch script that uses key states is pretty close to unimaginable. Actually... checking... yes, impossible since the usable keys are a-z,0-9,yp,down,left,right,space. Maybe there is something in that which can drive a useful heuristic?
> >> 
> >> Thanks so much for digging into this Dave.
> >> 
> >> tim
> >> --
> >> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> >> A flash of light, a cloud of dust, and...  What was the question?
> >> 
> >> 
> >> 
> > 
>