On Tue, Dec 16, 2008 at 10:25 PM, Peter Hutterer <[email protected]> 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 _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
