On Sat, Mar 04, 2023 at 10:07:54PM +0100, Henrik Carlqvist wrote: > On Wed, 1 Mar 2023 11:52:42 +0000 > Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> wrote: > > Another aspect to consider is whether keyboard_layout should just use > > standard strings, in which case it may not make sense to accept numeric hex > > values. > > I agree that those standard strings will make most sense to most people. > > However, as the choices of valid keyboard layouts are limited by the 64 values > allowed by the 6 bits on the dip switch I initially did choose to also truly > emulate the dip switch value as decimal or hexadecimal number to the -k > option. It might also be worth noting that the sun keyboard layouts have > multiple dip switch settings for a single language, probably with some minor > differences in keyboard layout or keyboard type. So both value 8 and 40 (0x28) > will give some norwegian keyboard layout. if someone, for some reason, would > want to emulate for example one of the four possible US keyboard layouts (0x0, > 0x1, 0x21 or 0x22) it would be harder to do without being able to give those > numerical values to the -k switch.
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" 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 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 regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|