qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5] Emulate dip switch language layout settings on SUN keyboa


From: Henrik Carlqvist
Subject: Re: [PATCH v5] Emulate dip switch language layout settings on SUN keyboard
Date: Tue, 28 Mar 2023 19:19:58 +0200

Thanks for your feedback!

On Tue, 28 Mar 2023 15:01:55 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:

> This is another reason why use of the '-k' switch is a bad idea. Its
> range of permissible values / vocabulary does not match the range of
> values / vocabulary needed for this hardware device.
> 
> In https://docs.oracle.com/cd/E19683-01/806-6642/new-43/index.html
> the keyboard layouts have distinct names
> 
> "Norway4" vs "Norway5" and "US4" vs  "US5" vs "US_UNIX5"

Those distinct names are names of files in the OS filesystem. This is a link
to a description of a patch which gives those keyboard layouts support for
the euro sign:

http://download.nust.na/pub3/solaris/patches/106839.readme

> I'd suggest a property to the escc device should take the names
> given by that reference page above. eg
> 
>   -global escc.sunkbd_layout=Norway4

Would you mind if such an assignment could also be given in multiple ways,
that is:

-global escc.sunkbd_layout=33
-global escc.sunkbd_layout=0x21
-global escc.sunkbd_layout=US5
-global escc.sunkbd_layout=en_us

would all result in the same dip switch setting 0x21? 

The nice thing with being able to assign keyboard layouts with a string like
"en_us" is that it does not require the user to read reference documentation
from Oracle to see which odd named layouts to choose from.

The nice thing to also being able to give numerical values like 33 or 0x21 is
that some possible dip switch settings (like 0x20) are not mentioned in the
Oracle reference documentation, but of course they would be possible to set
with physical dip switches even though they might not be supported by the OS.

> the only ambguity I see is that 0x0 and 0x1 both have the same
> name (US4), which could be resolved by handling 0x0 as the default
> with an empty string perhaps.

With multiple ways to give the values as I suggest it would be possible to
give 0x0 and 0x1 as values but "US4" would allways result in one of them,
probably 0x0. 

The default value when no value is given or when some invalid value is given
to escc.sunkbd_layout would preferably be 0x21 for backwards compability as
that is the only value you can get from the dip switch in qemu today.

Once we find a method we all agree on I am willing to rewrite my patch, but
maybe I will not be able to do it before summer when I get my vacation.

best regards Henrik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]