Hi, On 12 July 2012 23:27, Keith Packard <[email protected]> wrote: > Daniel Stone <[email protected]> writes: > >> You need to do at least some rudimentary stat() work so that you'll >> rebuild the keymap if the files it uses changes. > > My plan is to simply put that work on the package installer loading new > files into the xkb directories. A simple post-install hook that removed > all of the files in the server's cache directory should make that work
Ugh, please don't do that. I already get people (validly) complaining that XKB is unintuitive enough ... > I could make the in-server caching optional if you like, either command > line flag or configure option. Attempting to figure out which files are > relevant to stat seems like a huge effort. You could just do everything under the data root directory, although I guess spinning disks might not love that? >> Aside from that, it's our best hope short of forking xkbcommon, adding >> back some of the bits we removed as pointless, and smashing that into >> the server (volunteers?), so, why not. > > Even then, this avoids the cost of compilation, which isn't > insignificant. So, I think we want this regardless. Directly compiling > the file in the X server would avoid a whole pile of security drama, > otherwise it doesn't seem like a huge win (at least according to the > profiles I've seen). Eh? Admittedly this is with xkbcommon rather than xkbcomp, but if I compile keymaps (basic evdev/US) and then unref (i.e. free) them in a tight cycle, it takes me a steady 8.5ms per compilation. Admittedly this is with an SSD, but still, I'm having trouble figuring out where the 'compilation is super heavyweight and we can't do it ever' meme started. Even xkbcomp doesn't seem to be woefully slow, at least since 1.2.0's performance optimisations, plus having a libX11 which has all the keysyms in its table, rather than needing to go to XKeysymDB all the time. That being said, I'm not opposed to doing caching given that I don't really have any plans to merge xkbcomp in myself right now, but the package-manager thing (while attractive) is just a total copout, and will only lead to yet more confusion. Cheers, Daniel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
