Longtime Fedora user going rawhide (i915.modeset, keyboard layouts, xorg.conf/synaptics, bluetooth)

[MartinG]

Hi list, this is my first post here.

Having used (stable) Fedora since the very beginning, and also the
testing branch for some months now, I decided to go rawhide.
My setup is a pure install of Fedora 9 from the live-kde image (using
crypted partitions), later updated by "yum --enablerepo=rawhide update".

I have a Dell Latitude X1 (Intel mobile 915GM/GMS/910GML graphics
card, synaptics touchpad, smolt profile in [1])

I am a KDE 4 user, and I have searched this list [2].

Now for the questions:

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)?


2. Bluetooth. I used bluetooth with "great" success in F9 testing, but
in rawhide the service doesn't seem to start: Doing "service bluetooth
restart" gives neither "[  OK  ]" nor "[FAIL]". But, hm, just
now, I
started "bluetoothd" manually, and was able to do a "hcitool scan"
and
find my phone. The "kdebluetooth" tray icon is still reporting "No
bluetooth adapter", though. The update to rawhide also removed
/etc/bluetooth/hcid.conf and left /etc/sysconfig/bluetooth with all
lines commented out (not sure what I had before).

I know bluetooth support in KDE 4 is a bit broken at the moment, but I
just wanted to report on the possible issue in the bluetooth rc
scripts.

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)

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.

Thanks for all the great work so far, I hope I can contribute by
sending in bug reports. Any feedback appreciated.

-MartinG

[1] http://www.smolts.org/client/show/pub_01507560-2bed-4c14-94a5-c72964bb4b84
[2]
http://search.gmane.org/?query=stuff&author=&group=gmane.linux.re...
[3] http://airlied.livejournal.com/58778.html?thread=240794#t240794

[Adam Jackson]

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

[MartinG]

On Mon, Sep 22, 2008 at 4:08 PM, Adam Jackson <ajax(a)redhat.com&gt; wrote:
>  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. 
Thanks for the feedback. For now, I am able to start X when I don't use the
i915.modeset=1 kernel option.

> > 3. What is the grand plan for configuration replacement for the
> > xorg.conf file?
> > ... /etc/hal/fdi/policy/10-synaptics.fdi, ... 
>  You can do it there, or you can do it in xorg.conf like you've
> always
>  done.  In fact, the latter is preferred. 
Ok, just to share how I was able to use synaptics "the way it was before":
I removed xorg.conf, started X, went into /var/log/Xorg.0.log, cut the
autoconfig
section there, put it back into /etc/X11/xorg.conf, and added these lines
(relevant for synaptics with (usable) tapping,
and intel (to work with compiz-fusion in KDE4):

Section "Device"
        Identifier      "Builtin Default intel Device 0"
        Driver  "intel"
        # "opera: X Shared memory extension is not available. ZPixmap
not supported"
        # read:
http://linux-tipps.blogspot.com/2008/06/operaintel-x-shared-memory-proble...
        Option      "AccelMethod" "XAA" # not EXA
        # read:  http://forum.compiz-fusion.org/showthread.php?t=8119
        Option "XAANoOffscreenPixmaps" "true"
EndSection

Section "InputDevice"
        Identifier  "Synaptics"
        Driver      "synaptics"
        Option      "Device" "/dev/input/mice"
        Option      "Protocol" "auto-dev"
        Option      "Emulate3Buttons" "yes"
        Option      "SHMConfig" "true"
# Turn off horizontal scroll:
        Option      "HorizScrollDelta" "0"
        Option      "TapButton1" "1"
        Option      "TapButton2" "2"
        Option      "TapButton2" "3"
# Make tapping work "the old way", ie. usable way:
        Option      "MaxTapMove" "2000"
EndSection

(this config seems to survive suspend/resume, nice)

Now X starts fine, but when I scroll in eg. 'konsole' I sometimes get
wierd behavior: If I scroll up, the upper half of the screen stays
static, but when I scroll down, the lower half of the screen stays
static (doesn't "follow"). Said in another way - the scrolling seems
to miss lines. Same thing happens sometimes, in Opera (web browser).
Furthermore, dmesg keeps reporting

[drm:i915_gem_execbuffer] *ERROR* Going to lose the write domain on
obj 26 size 16777216
[drm:i915_gem_execbuffer] *ERROR* Going to lose the write domain on
obj 27 size 16777216

and .xsession-errors shows:

X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 20 (X_GetProperty)
  Resource id:  0x304def9
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  20
  Minor opcode:  0
  Resource id:  0x2a38d26


>  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. 
Okay, I can live without the 'nodeadkeys' option. I'll try some more when the
next KDE4 update arrives.

>  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! 
Sounds like a nice plan, but I assume this is meant to be in addition
to some user specific settings?

>  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. 
Okay, this is what I did:
- Started KDE with the working keyboard (no keyboard mentioned in
xorg.conf, and layouts disabled in KDE systemsetting/regional..)
$ xkbcomp :0 - &> xkbcomp0-_without-kde-layouts.txt

- enabled layouts in systemsettings (english, norwegian and norwegian
nodeadkeys),
this broke the keyboard, only normal alphabet work, arrow keys are
mapped to something
else (not sure what, but one of them mean something like "delete to
the en of the line" in this webmail editor)
$ xkbcomp :0 - &> xkbcomp0-_with-kde-layouts.txt

- disabled layouts
$ xkbcomp :0 - &> xkbcomp0-_disabled-kde-layouts.txt
$ diff -u xkbcomp0-_with-kde-layouts.txt  xkbcomp0-_disabled-kde-layouts.txt
(no output, ie. no difference, therefore not attached)

see attachments

So I have to restart KDE to get back to a working keyboard.

Thanks!

-MartinG

[Gilboa Davara]

On Mon, 2008-09-22 at 13:53 +0200, MartinG wrote:

>  2. Bluetooth. I used bluetooth with "great" success in F9
> testing, but
>  in rawhide the service doesn't seem to start: Doing "service bluetooth
>  restart" gives neither "[  OK  ]" nor "[FAIL]". But, hm, just
> now, I
>  started "bluetoothd" manually, and was able to do a "hcitool scan"
> and
>  find my phone. The "kdebluetooth" tray icon is still reporting "No
>  bluetooth adapter", though. The update to rawhide also removed
>  /etc/bluetooth/hcid.conf and left /etc/sysconfig/bluetooth with all
>  lines commented out (not sure what I had before).
>  
>  I know bluetooth support in KDE 4 is a bit broken at the moment, but I
>  just wanted to report on the possible issue in the bluetooth rc
>  scripts. 
kdebluetooth4 has just been pushed to update testing.
While missing a number of major features compared to its KDE 3.5.x
version (notably ioslaves integration) - it should be far more stable.

Please test and report bugs (preferably upstream [ http://bugs.kde.org ]
and CC me to them)

- Gilboa

[Kevin Kofler]

MartinG <gronslet <at> gmail.com> writes:
>  - Started KDE with the working keyboard (no keyboard mentioned in
>  xorg.conf, and layouts disabled in KDE systemsetting/regional..)
>  $ xkbcomp :0 - &> xkbcomp0-_without-kde-layouts.txt
>  
>  - enabled layouts in systemsettings (english, norwegian and norwegian
>  nodeadkeys),
>  $ xkbcomp :0 - &> xkbcomp0-_with-kde-layouts.txt 
Looks like the first difference is this:
>  xkb_keycodes "evdev+aliases(qwerty)" { 
vs.:
>  xkb_keycodes "xfree86+aliases(qwerty)" { 
Is that already the problem?

        Kevin Kofler

[Kevin Kofler]

MartinG <gronslet <at> gmail.com> writes:
>  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. 
There's an option for "evdev-managed keyboard", you just have to check
that.

But it should be the default in F10, bug report filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=464101
We're looking into it.

        Kevin Kofler

[MartinG]

On Fri, Sep 26, 2008 at 12:05 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  There's an option for "evdev-managed keyboard", you
> just have to check that.
>
>  But it should be the default in F10, bug report filed here:
>  https://bugzilla.redhat.com/show_bug.cgi?id=464101
>  We're looking into it. 
OK, thanks, just tried it and it seems to work just fine.
I guess this also answers your other post in this thread:
 "evdev+aliases(qwerty)"  vs."xfree86+aliases(qwerty)".

Honestly, I didn't know anything about neither evdev nor xfree86 keyboard
backends, but now I know a little bit more, and the problem seems to be solved.
Thanks!

-MartinG

[MartinG]

On Thu, Sep 25, 2008 at 6:24 PM, Gilboa Davara <gilboad(a)gmail.com&gt; wrote:
>  kdebluetooth4 has just been pushed to update testing.
>  While missing a number of major features compared to its KDE 3.5.x
>  version (notably ioslaves integration) - it should be far more stable. 
I can't seem to find it, am I doing anything wrong here..?:
# yum --enablerepo=rawhide,updates-testing-newkey install kdebluetooth4
...
No package kdebluetooth4 available.
Nothing to do

Also, seems that I've got the old package twice:
# rpm -qa kdeblue\*
kdebluetooth-1.0-0.43.beta8.fc10.i386
kdebluetooth-libs-1.0-0.43.beta8.fc10.i386
kdebluetooth-libs-1.0-0.41.beta8.fc9.i386

Maybe something got messed up in the transition to rawhide...
Any tips on how to clean things up appreciated!

-MartinG
(kernel 2.6.27-0.352.rc7.git1.fc10.i686)

[Gilboa Davara]

On Mon, 2008-09-29 at 12:22 +0200, MartinG wrote:
>  On Thu, Sep 25, 2008 at 6:24 PM, Gilboa Davara
> <gilboad(a)gmail.com&gt; wrote:
>  > kdebluetooth4 has just been pushed to update testing.
>  > While missing a number of major features compared to its KDE 3.5.x
>  > version (notably ioslaves integration) - it should be far more stable.
>  
>  I can't seem to find it, am I doing anything wrong here..?:
>  # yum --enablerepo=rawhide,updates-testing-newkey install kdebluetooth4
>  ...
>  No package kdebluetooth4 available.
>  Nothing to do
>  
>  Also, seems that I've got the old package twice:
>  # rpm -qa kdeblue\*
>  kdebluetooth-1.0-0.43.beta8.fc10.i386
>  kdebluetooth-libs-1.0-0.43.beta8.fc10.i386
>  kdebluetooth-libs-1.0-0.41.beta8.fc9.i386
>  
>  Maybe something got messed up in the transition to rawhide...
>  Any tips on how to clean things up appreciated!
>  
>  -MartinG
>  (kernel 2.6.27-0.352.rc7.git1.fc10.i686)
>   
To keep the noise down, it's still being called kdebluetooth.

- Gilboa

[Michal Jaegermann]

On Mon, Sep 29, 2008 at 12:22:00PM +0200, MartinG wrote:
>  
>  Also, seems that I've got the old package twice:
>  # rpm -qa kdeblue\*
>  kdebluetooth-1.0-0.43.beta8.fc10.i386
>  kdebluetooth-libs-1.0-0.43.beta8.fc10.i386
>  kdebluetooth-libs-1.0-0.41.beta8.fc9.i386 
'package-cleanup --cleandupes' if you do not want to do that just
yourself with rpm.  You need 'yum-utils' package installed for
'package-cleanup' to be available.

Once there run that command also with flags like '--orphans' and
'--problems'.

  Michal

[Patrick O'Callaghan]

On Mon, 2008-09-29 at 16:28 +0300, Gilboa Davara wrote:
>  On Mon, 2008-09-29 at 12:22 +0200, MartinG wrote:
>  > On Thu, Sep 25, 2008 at 6:24 PM, Gilboa Davara <gilboad(a)gmail.com&gt; wrote:
>  > > kdebluetooth4 has just been pushed to update testing.
>  > > While missing a number of major features compared to its KDE 3.5.x
>  > > version (notably ioslaves integration) - it should be far more stable.
>  > 
>  > I can't seem to find it, am I doing anything wrong here..?:
>  > # yum --enablerepo=rawhide,updates-testing-newkey install kdebluetooth4
>  > ...
>  > No package kdebluetooth4 available.
>  > Nothing to do
>  > 
>  > Also, seems that I've got the old package twice:
>  > # rpm -qa kdeblue\*
>  > kdebluetooth-1.0-0.43.beta8.fc10.i386
>  > kdebluetooth-libs-1.0-0.43.beta8.fc10.i386
>  > kdebluetooth-libs-1.0-0.41.beta8.fc9.i386
>  > 
>  > Maybe something got messed up in the transition to rawhide...
>  > Any tips on how to clean things up appreciated!
>  > 
>  > -MartinG
>  > (kernel 2.6.27-0.352.rc7.git1.fc10.i686)
>  > 
>  
>  To keep the noise down, it's still being called kdebluetooth. 
For some values of "noise". The actual executables are called
kbluetooth4 etc. (*not* kdebluetooth4 or whatever). I don't remember if
it was always like that but it is a bit confusing. Some consistency in
this would be appreciated.

poc

[Gilboa Davara]

On Mon, 2008-09-29 at 10:17 -0430, Patrick O'Callaghan wrote:
>  On Mon, 2008-09-29 at 16:28 +0300, Gilboa Davara wrote:
>  > On Mon, 2008-09-29 at 12:22 +0200, MartinG wrote:
>  > > On Thu, Sep 25, 2008 at 6:24 PM, Gilboa Davara <gilboad(a)gmail.com&gt;
> wrote:
>  > > > kdebluetooth4 has just been pushed to update testing.
>  > > > While missing a number of major features compared to its KDE 3.5.x
>  > > > version (notably ioslaves integration) - it should be far more stable.
>  > > 
>  > > I can't seem to find it, am I doing anything wrong here..?:
>  > > # yum --enablerepo=rawhide,updates-testing-newkey install kdebluetooth4
>  > > ...
>  > > No package kdebluetooth4 available.
>  > > Nothing to do
>  > > 
>  > > Also, seems that I've got the old package twice:
>  > > # rpm -qa kdeblue\*
>  > > kdebluetooth-1.0-0.43.beta8.fc10.i386
>  > > kdebluetooth-libs-1.0-0.43.beta8.fc10.i386
>  > > kdebluetooth-libs-1.0-0.41.beta8.fc9.i386
>  > > 
>  > > Maybe something got messed up in the transition to rawhide...
>  > > Any tips on how to clean things up appreciated!
>  > > 
>  > > -MartinG
>  > > (kernel 2.6.27-0.352.rc7.git1.fc10.i686)
>  > > 
>  > 
>  > To keep the noise down, it's still being called kdebluetooth.
>  
>  For some values of "noise". The actual executables are called
>  kbluetooth4 etc. (*not* kdebluetooth4 or whatever). I don't remember if
>  it was always like that but it is a bit confusing. Some consistency in
>  this would be appreciated.
>  
>  poc
>   
If upstream calls the project kdebluetooth I cannot really call it
kbluetooth, can I.
For obvious reasons, upstream decided to name the KDE 4.x version of the
kdebluetooth kdebluetooth4; however, renaming the package under F9's
feet could have generated a lot of problems - hence, I decided to keep
the kdebluetooth name.

- Gilboa

[Patrick O'Callaghan]

On Tue, 2008-09-30 at 02:55 +0300, Gilboa Davara wrote:
>  If upstream calls the project kdebluetooth I cannot really call it
>  kbluetooth, can I. 
My comment wasn't really directed at you, it's just an observation.

poc