On Mon, 2008-09-22 at 13:53 +0200, MartinG wrote: > 1. The modesetting driver for the intel card doesn't seem to be > included in the latest kernel (2.6.27-0.329.rc6.git2.fc10.i686) -- > adding "i915.modeset=1" as a kernel parameter in /etc/grub.conf gives > an error "unknown boot option, ignoring". This is also mentioned by > Rex Dieter in airlied's blog [3]. Also, if I try to boot with that > option, I am able to log in to X, but then X freezes and fills my > /var/log/Xorg.0.log with *many* lines like > > .. > exaCopyDirty: Pending damage region empty! > [mi] EQ overflowing. The server is probably stuck in an infinite loop. > [mi] mieqEnequeue: out-of-order valuator event; dropping. > [mi] EQ overflowing. The server is probably stuck in an infinite loop. > [mi] mieqEnequeue: out-of-order valuator event; dropping. > .. > > Is there any plan to include the modesetting driver for intel again? > Should I file a bug, if so -- where (what product)? Intel KMS support is likely to miss F10, it doesn't look to be in working shape upstream let alone in fedora. The command line option should work for the "keep both pieces" crowd though. > 3. What is the grand plan for configuration replacement for the > xorg.conf file? I've read that eg. options for the synaptics touchpad > driver can be put in /etc/hal/fdi/policy/10-synaptics.fdi, and I have > fiddled a bit around with it. Are we all supposed to hardcode xml > files now, or are all windows managers meant to provide GUIs for > these? (not a rant, just an honest question) You can do it there, or you can do it in xorg.conf like you've always done. In fact, the latter is preferred. The grand vision is that all the interesting options you can set will be settable at runtime, and that the desktop environment will save your settings and restore them when you log in. gnome-display-properties mostly has this hooked up for RANDR settings, and we're hoping to have input device properties land by F11 so you can do the same for synaptics and whatever else. But in the meantime, yes, edit xorg.conf like normal. > 4. Possibly related to the non-existent xorg.conf file, I had some > serious issues with the keyboard when enabling keyboard layouts in KDE > systemsettings. Specifically, some keys where mapped wrong, some > didn't work at all (eg. the arrow keys). Disabling keyboard layouts in > KDE 4, and restarting X "solves" the problem, but how do I enable the > "nodeadkeys" variant of my Norwegian keyboard? Making a .fdi file? Any > hints appreciated. With the evdev driver, keyboard settings are inherited from the settings in /etc/sysconfig/keyboard, which you can set by running system-config-keyboard. Well, some of which you can set; really all s-c-k lets you set is layout. The script to propagate these settings into hal is in /usr/bin/fedora-setup-keyboard and it's probably one of the more vile hacks I've ever written. Sorry about that. I had a plan, at one point, to add something to that script that would let you set additional XKB options directly from /e/s/k, so you could do something like: KEYTABLE=no XKB_OPTIONS=nodeadkeys and have it work. But it doesn't yet. I'd happily take a patch! But the real problem there is that when KDE applied its session settings, something screwed up. The output from 'xkbcomp :0 -' from the broken configuration would be useful here. I suspect what's happening is KDE's trying to change the xkb 'model' to pc105, which isn't meaningful for evdev. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list