Let the DDX decide on the XkbRulesDefaults.

[Dan Nicholson]

On Tue, Dec 16, 2008 at 10:25 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Wed, Dec 17, 2008 at 05:17:19PM +1100, Daniel Stone wrote:
>> On Tue, Dec 16, 2008 at 09:17:13PM -0800, Keith Packard wrote:
>> > On Wed, 2008-12-17 at 07:52 +1000, Peter Hutterer wrote:
>> > > XkbSetRulesDflts only sets some internal defaults but doesn't actually use
>> > > them much. XkbInitKeyboardDeviceStruct then calls XkbGetRulesDftls which
>> > > returns either the ones set by the DDX, or the defaults. A DDX that doesn't
>> > > have set the rules simply defaults to the built-in ones.
>> >
>> > Thanks. I'll merge those changes in to 1.6 then. Just making sure we
>> > wouldn't be breaking non-xfree86-based servers.
>>
>> You can if you want, but I don't really see the point.  The way drivers
>> do RMLVO configuration right now is to call XkbSetRulesDflts and then
>> XkbInitKeyboardDeviceStruct, which picks up those 'defaults'.  Awesome.
>
> The point was the gnome keycode issue which keeps reappearing.
> Setting the keymap to evdev by the DDX initially means gnome picks up the
> right keymap and doesn't give us pretty screenshots each time we hit "up".
> And we need the DDX to set it, because that's the only entity that knows
> whether we will have evdev lateron (AEI is on) or will stick to kbd (AEI is
> off).

The other reason I had in mind was to tie into the keymap cache patch
I sent. Smarter default means better chance you can reuse the cached
map. And I definitely agree that the the XkbSetRulesDflts API is not
exactly the way you'd envision things working. Would it be better at
some point to have a new function where the driver just passes in the
RMLVO it wants instead of setting new defaults and then passing in a
(probably empty) XkbComponentNamesRec? Then the DDX could just set the
defaults once instead of having them continually blown away.

--
Dan