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.



-- 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?
>> 
>> 
>> 
>