Fw: "sticky" xkb options ?
peter.hutterer at who-t.net
Sun Aug 21 14:53:55 PDT 2011
On Sun, Aug 21, 2011 at 06:29:32AM -0400, Marty Jack wrote:
> On 08/21/2011 12:44 AM, Alan Coopersmith wrote:
> > On 08/20/11 12:45, Alan Coopersmith wrote:
> >> On 08/20/11 11:50, Matthieu Herrb wrote:
> >>> And sticky xkboptions could be useful for other options too, given
> >>> that a way to reset them explicitely also exist.
> >> Yes, an "XkbOptionsAdd" or similar to append instead of clear/set would
> >> be very nice. It would need to handle autoadding the , separator between
> >> entries, but that shouldn't be hard.
> > Actually I guess it would be OptionAppend "XkbOptions" instead of
> > Option "XkbOptionsAdd", since the option parser would need to know
> > to do the append instead of just replacing the existing value for
> > that option.
> You could get into a definitional/user misunderstanding nightmare if this
> isn't carefully thought through. The server gets all done with startup
> and xorg.conf.d and later someone does a "setxkbmap" or if the DE does one
> behind your back. What happens then. Do the OptionAppends stay or
we've always treated the server configuration as separate from any run-time
configuration. the same would be true here, once the server finishes
initialising a device, any user-space tools will simply overwrite the
server. The same rule would apply here.
More information about the xorg