Re: [PATCH 3/5] Input: pinephone-keyboard - Build in the default keymap

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

 



On Tue, Apr 12, 2022 at 08:20:24PM +1000, Jarrah wrote:
> 
> On 1/30/22 10:00, Samuel Holland wrote:
> > +
> > +static const uint32_t ppkb_default_fn_keymap[] = {
> > +	KEY(0,  0, KEY_FN_ESC),
> > +	KEY(0,  1, KEY_F1),
> > +	KEY(0,  2, KEY_F2),
> > +	KEY(0,  3, KEY_F3),
> > +	KEY(0,  4, KEY_F4),
> > +	KEY(0,  5, KEY_F5),
> > +	KEY(0,  6, KEY_F6),
> > +	KEY(0,  7, KEY_F7),
> > +	KEY(0,  8, KEY_F8),
> > +	KEY(0,  9, KEY_F9),
> > +	KEY(0, 10, KEY_F10),
> > +	KEY(0, 11, KEY_DELETE),
> > +
> > +	KEY(2,  0, KEY_SYSRQ),
> > +	KEY(2, 10, KEY_INSERT),
> > +
> 
> 
> The driver currently being patched into most distros supporting the keyboard
> exposes the symbols printed on the keyboard rather than the F* keys on the
> function layer. While I agree than exposing function keys on the Fn layer is
> more logical, in practice running this patch for a day I've found it's far
> more useful to have quick access to the standard set of symbols (such as |
> and -) than to have the function keys.
> 
> Would it be possible to either set the default back to symbols or expose
> another layer (potentially under the "pine" key)? An alternative solution
> proposed on the Mobian issue for this was to add a module option, allowing
> these to be switched at runtime rather than compile time.

You will not get access to all the symbols anyway, this way. You should solve
this via xkb and kernel keymaps (man keymaps(5)). Normal users should not be
modifying basic keymap in DT or the driver anyway.

kind regards,
	o.



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux