[9front] vnc: fix farsi key symbols

[9front] vnc: fix farsi key symbols

[unobe]

Could someone explain the commit today for fixing farsi key symbols a
bit more?  Is this for vncs or vncv?  I assume vncv is more useful
nowadays due to drawterm, but perhaps not.

 From https://cgit.freedesktop.org/xorg/proto/x11proto/tree/keysymdef.h
, lines 60-81 describe the state of affairs (presumably from the last
copyright year at the top of the file, 1998).  If we want to remain
compatible with connecting to older server implementations, then would
it be better to do similar to what is done around line 91 from
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.desktop/unix/classes/sun/awt/X11/XKeysym.java
? That is, revert the changes to /sys/src/cmd/vnc/utf2ksym.h and
handle the discrepancy more generally in /sys/src/cmd/vnc/kbdv.c ? Or
do we just not care?

Re: [9front] vnc: fix farsi key symbols

[Jacob Moody]

On 5/16/23 18:43, unobe@cpan.org wrote:
> Could someone explain the commit today for fixing farsi key symbols a
> bit more?  Is this for vncs or vncv?  I assume vncv is more useful
> nowadays due to drawterm, but perhaps not.
> 
>  From https://cgit.freedesktop.org/xorg/proto/x11proto/tree/keysymdef.h
> , lines 60-81 describe the state of affairs (presumably from the last
> copyright year at the top of the file, 1998).  If we want to remain
> compatible with connecting to older server implementations, then would
> it be better to do similar to what is done around line 91 from
> https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.desktop/unix/classes/sun/awt/X11/XKeysym.java
> ? That is, revert the changes to /sys/src/cmd/vnc/utf2ksym.h and
> handle the discrepancy more generally in /sys/src/cmd/vnc/kbdv.c ? Or
> do we just not care?
> 
> 

I was told these were pulled from the openbsd keysymdef.h.
I dont currently have an openbsd around but I believe this is the file, and these lines specifically:

https://github.com/openbsd/xenocara/blob/d1a8d3ab034044bab40925e51534100a444dd3d6/proto/xorgproto/include/X11/keysymdef.h#L1011-L1100

It seems that they have elected to make the "new" unicode mapping the default, alongside the existing older keysyms in a similar way this
patch does. Likewise the X11/keysym.h on my local loonix system has the same mapping. I agree that on paper the use of the new mappings
for these codepoints specifically is a bit weird, but it seems to be consistently weird with "upstream".

thanks,
moody

Re: [9front] vnc: fix farsi key symbols

[unobe]

Quoth Jacob Moody <moody@mail.posixcafe.org>:
> I was told these were pulled from the openbsd keysymdef.h.
> I dont currently have an openbsd around but I believe this is the file, and these lines specifically:
> 
> https://github.com/openbsd/xenocara/blob/d1a8d3ab034044bab40925e51534100a444dd3d6/proto/xorgproto/include/X11/keysymdef.h#L1011-L1100
> 
> It seems that they have elected to make the "new" unicode mapping the default, alongside the existing older keysyms in a similar way this
> patch does. Likewise the X11/keysym.h on my local loonix system has the same mapping. I agree that on paper the use of the new mappings
> for these codepoints specifically is a bit weird, but it seems to be consistently weird with "upstream".

Thanks moody.

In that case, more mappings like Arabic percent, the Arabic digits
(not Farsi) etc.  could be updated to match.  But that's for another
day.

As a side note which made me interested in this patch: I've only
recently started using more Arabic, but haven't used it via VNC,
mainly because the computer I'd VNC into has a much higher resolution
than my 9front display, so I only see a portion of the screen.  I
don't see an easy way to scale the viewing window like some other VNC
viewers do.  So being able to scale, or have the ability to view a
different part of the remote buffer, is a blocker.

Re: [9front] vnc: fix farsi key symbols

[Jacob Moody]

On 5/16/23 20:38, unobe@cpan.org wrote:
> Quoth Jacob Moody <moody@mail.posixcafe.org>:
>> I was told these were pulled from the openbsd keysymdef.h.
>> I dont currently have an openbsd around but I believe this is the file, and these lines specifically:
>>
>> https://github.com/openbsd/xenocara/blob/d1a8d3ab034044bab40925e51534100a444dd3d6/proto/xorgproto/include/X11/keysymdef.h#L1011-L1100
>>
>> It seems that they have elected to make the "new" unicode mapping the default, alongside the existing older keysyms in a similar way this
>> patch does. Likewise the X11/keysym.h on my local loonix system has the same mapping. I agree that on paper the use of the new mappings
>> for these codepoints specifically is a bit weird, but it seems to be consistently weird with "upstream".
> 
> Thanks moody.

Thank you for the first mail, the links had some good context to read through.
There is likely some explanation for why these specific codepoints use the new format.
If there is some consistent rule, maybe it could be refactored.

> 
> In that case, more mappings like Arabic percent, the Arabic digits
> (not Farsi) etc.  could be updated to match.  But that's for another
> day.

I also saw other codepoints that were defaulted to the new mapping when
perusing the file. Perhaps a full sync is in order? Is there value in
keeping these old tables around for old software? I am not too sure.

> 
> As a side note which made me interested in this patch: I've only
> recently started using more Arabic, but haven't used it via VNC,
> mainly because the computer I'd VNC into has a much higher resolution
> than my 9front display, so I only see a portion of the screen.  I
> don't see an easy way to scale the viewing window like some other VNC
> viewers do.  So being able to scale, or have the ability to view a
> different part of the remote buffer, is a blocker.
> 

It should be possible to create virtual 'headless' vnc servers of arbitrary resolutions.
Maybe that will work in your case. I tend to go the other way with drawterm most of the time.

thanks,
moody

Re: [9front] vnc: fix farsi key symbols

[ori]

Quoth unobe@cpan.org:
> Quoth Jacob Moody <moody@mail.posixcafe.org>:
> > I was told these were pulled from the openbsd keysymdef.h.
> > I dont currently have an openbsd around but I believe this is the file, and these lines specifically:
> > 
> > https://github.com/openbsd/xenocara/blob/d1a8d3ab034044bab40925e51534100a444dd3d6/proto/xorgproto/include/X11/keysymdef.h#L1011-L1100
> > 
> > It seems that they have elected to make the "new" unicode mapping the default, alongside the existing older keysyms in a similar way this
> > patch does. Likewise the X11/keysym.h on my local loonix system has the same mapping. I agree that on paper the use of the new mappings
> > for these codepoints specifically is a bit weird, but it seems to be consistently weird with "upstream".
> 
> Thanks moody.
> 
> In that case, more mappings like Arabic percent, the Arabic digits
> (not Farsi) etc.  could be updated to match.  But that's for another
> day.
> 
> As a side note which made me interested in this patch: I've only
> recently started using more Arabic, but haven't used it via VNC,
> mainly because the computer I'd VNC into has a much higher resolution
> than my 9front display, so I only see a portion of the screen.  I
> don't see an easy way to scale the viewing window like some other VNC
> viewers do.  So being able to scale, or have the ability to view a
> different part of the remote buffer, is a blocker.
> 

Typically, I use tigervnc, which scales the resolution of the remote
virtual X11 server to match the resolution of the output window.

Re: [9front] vnc: fix farsi key symbols

[unobe]

Quoth Jacob Moody <moody@mail.posixcafe.org>:
> I also saw other codepoints that were defaulted to the new mapping
> when perusing the file.  Perhaps a full sync is in order?  Is there
> value in keeping these old tables around for old software?  I am not
> too sure.

Yeah, perhaps a full(er) sync.

> It should be possible to create virtual 'headless' vnc servers of arbitrary resolutions.
> Maybe that will work in your case. I tend to go the other way with drawterm most of the time.

I haven't tried configuring the headless approach more--the remote
buffer is a macbook.  But yeah, I generally use drawterm, yet I have
had an issue with drawterm on dual monitors if the drawterm window is
on the external monitor--the mouse moves to the laptop's main monitor
on an action that moves the cursor (e.g., right-clicking in acme).  I
investigated briefly sometime last year to see if I could fix, and
could not.  IIRC, the mouse position always considers its movement in
the context of the main monitor.  So that restricts my usage of
drawterm to the main (laptop) monitor which has a higher resolution,
but not as big.

Re: [9front] vnc: fix farsi key symbols

[unobe]

Quoth ori@eigenstate.org:
> Typically, I use tigervnc, which scales the resolution of the remote
> virtual X11 server to match the resolution of the output window.

Thanks, ori.

I was trying to go from the other direction using vncv(1), and using
Mac OS X's native VNC server.

Re: [9front] vnc: fix farsi key symbols

[ori]

Quoth unobe@cpan.org:
> Quoth ori@eigenstate.org:
> > Typically, I use tigervnc, which scales the resolution of the remote
> > virtual X11 server to match the resolution of the output window.
> 
> Thanks, ori.
> 
> I was trying to go from the other direction using vncv(1), and using
> Mac OS X's native VNC server.
> 

I should clarify: I use tigervnc as the server, and vncv as the
client. Resizing the client window in vncv(1) will resize the
server's framebuffer.

Re: [9front] vnc: fix farsi key symbols

[unobe]

Quoth ori@eigenstate.org:
> Quoth unobe@cpan.org:
> > Quoth ori@eigenstate.org:
> > > Typically, I use tigervnc, which scales the resolution of the remote
> > > virtual X11 server to match the resolution of the output window.
> > 
> > Thanks, ori.
> > 
> > I was trying to go from the other direction using vncv(1), and using
> > Mac OS X's native VNC server.
> > 
> 
> I should clarify: I use tigervnc as the server, and vncv as the
> client. Resizing the client window in vncv(1) will resize the
> server's framebuffer.

Oh, sorry for misunderstanding; that makes sense.  I was looking at
the RFB protocol and saw there is a way to specify the desktop size,
so I think it can be set from the client-side too.  Specifically
/sys/src/cmd/vnc/draw.c:/^requestupdate would need updating to either
allow viewing a different area of the remote frame buffer. Or maybe
there's another configuration knob that can be turned to scale.

Anyway, thanks again for the clarification.

Re: [9front] vnc: fix farsi key symbols

[ori]

Quoth unobe@cpan.org:
> Oh, sorry for misunderstanding; that makes sense.  I was looking at
> the RFB protocol and saw there is a way to specify the desktop size,
> so I think it can be set from the client-side too. 

We already do this -- see MSetDesktopSize in
/sys/src/cmd/draw.c:/^requestupdate

Re: [9front] vnc: fix farsi key symbols

[unobe]

Quoth ori@eigenstate.org:
> Quoth unobe@cpan.org:
> > Oh, sorry for misunderstanding; that makes sense.  I was looking at
> > the RFB protocol and saw there is a way to specify the desktop size,
> > so I think it can be set from the client-side too. 
> 
> We already do this -- see MSetDesktopSize in
> /sys/src/cmd/draw.c:/^requestupdate
> 
> 

Thanks ori.

Indeed, I saw that.  However, it only occurs if the server lets the
client resize the frame buffer and the dimensions of the rc window is
not equal to the server's frame buffer.  In the case of OS X's stock
VNC server, I confirmed that the server doesn't allow resizing (it
doesn't send the ExtendedDesktopSize message), so apparently that
won't work for my situation.

Maybe I want vncv to have a vertical and horizontal scroller to view
different areas of the frame buffer, or some other mechanism to view
different portions of the screen.  Or perhaps scale the raw buffer to
a pre-determined dimension (which I think might be more complicated).
Anyway, one other thing on the ever-growing todo/wish list, and which
will be a learning experience.

Re: [9front] vnc: fix farsi key symbols

[mkf9]

unobe@cpan.org wrote:
> Could someone explain the commit today for fixing farsi key symbols a
> bit more?  Is this for vncs or vncv?  I assume vncv is more useful
> nowadays due to drawterm, but perhaps not.


Hi, sorry for late reply.
this patch only fixes vncv->tigervnc, vncv->vncs works already.
the reason I didn't updated other keysyms is we don't currently have an 
Arabic/Urdu/etc kbmap to type those characters.