From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18795 invoked from network); 17 May 2023 02:11:26 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 17 May 2023 02:11:26 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Tue May 16 22:09:09 -0400 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1684289407; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zsmukv4HH/+na96gFiz+Blv4q46LR/0u2AE+d2k2BlA=; b=o8Qf03YLzNuNwgMUiO+VUZAZvI6vYmDeDxD93kBn5s4BqySoxG0GRuehQtjW/2GA3s/2GN oKfpmJpuccQNNywrxFDp26YiVoEKKlIjopTL3cVGfPXJUBGTV4T+Wx/ZrlrR9qfpPl1wgt PAwSBsPe8QaXXF58LrTx085ZfL0hBDA= Received: from [192.168.168.200] (161-097-205-025.v4.mynextlight.net [161.97.205.25]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id ef38e813 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Tue, 16 May 2023 21:10:06 -0500 (CDT) Message-ID: Date: Tue, 16 May 2023 20:08:59 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Content-Language: en-US To: 9front@9front.org References: From: Jacob Moody In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: generic realtime-java realtime-oriented descriptor Subject: Re: [9front] vnc: fix farsi key symbols Reply-To: 9front@9front.org Precedence: bulk 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