Bug 374101

Created attachment 204110 [details]
yast logs

Created attachment 204111 [details]
this was my xorg.conf right after the installation

Interesting in the log certainly is:

Section "InputDevice"
  Driver       "synaptics"
  Identifier   "Mouse[0]"
  Option       "Protocol" "auto-dev"
EndSection


Section "InputDevice"
  Driver       "synaptics"
  Identifier   "Mouse[1]"

...

Section "ServerLayout"
  Identifier   "Layout[all]"
  InputDevice  "Mouse[0]" "CoreKeyboard"

A xorg.conf without keyboard driver section is indeed bad.

installation issue

No idea why "installation issue"

this happens at the beginning of the installation. no keyboard
is present this is outside of my responsibilities

thanks

Lukas, Marcus, so whose bug is this?

Please don't ping-pong bugs back to yast2-maintainers. If the maintainers of the involved YaST2 subsystems don't know how to proceed, how should the bug-distributor-of-the-month know?

Mouse.ycp:169 key xqfj.FwiAbOpAKz9 conf $["available":`unknown, "configured":`unknown, "info":`unknown, "needed":`unknown]
Mouse.ycp:169 key KRJj.JrMVjT9Ur0E conf $["available":`unknown, "configured":`unknown, "info":`unknown, "needed":`unknown]
Mouse.ycp:169 key 8e8U.LvZ6x385xhC conf $["available":`unknown, "configured":`unknown, "info":`unknown, "needed":`unknown]
Mouse.ycp:202 tl = [["Keine", $["device":"", "emul3":false, "gpm":"", "id":"none", "mset":"", "wheels":0]]]
Mouse.ycp:210 found mouse none

Mouse.ycp:213 No mouse found, probed '[$["bus":"USB", "bus_hwcfg":"usb", "class_id":261, "dev_name":"/dev/input/mice" ... $["bus":"USB", "bus_hwcfg":"usb", "class_id":261, "compat_device":"Generic USB Mouse", "compat_vendor":"Unknown", "device":"Apple Internal Keyboard / Trackpad", "device_id":197144, "hotplug":"usb", "modalias":"usb:v05ACp0218d0064dc00dsc00dp00ic03isc01ip02", "model":"Apple Internal Keyboard / Trackpad", ... ]

Mouse.ycp:275 Mouse::Set (none)
Mouse.ycp:297 Mouse 'none', name 'Keine'

"device":"Apple Internal Keyboard / Trackpad" is detected as "compat_device":"Generic USB Mouse" ...

>>> This is not related to the installation framework
>>> 'hwinfo' vs 'yast2-mouse'

http://googlefight.com/index.php?lang=en_GB&word1=hwinfo&word2=yast2-mouse

please attach the log of 'hwinfo --mouse --keyboard --log=foo'

Created attachment 205006 [details]
hwinfo --mouse --keyboard --log=foo

here is the hwinfo

hwinfo shows two keyboards and three mice. What exactly is the problem?

I still don't know why this bug is assigned to me. If I understand the
reporter correctly the installation procedure doesn't have a keyboard
from the beginning on. I'm not responsible for this first setup of
input devices like keyboard mouse etc...

In the first phase of installation I did have keyboard and was able to enter user name and password for example.

But my installed system (and the second phase of the installation) had the broken Xorg configuration.


 

(In reply to comment #12 from Steffen Winterfeldt)
> hwinfo shows two keyboards and three mice. What exactly is the problem?

My system has one internal keyboard the internal touchpad and an external logitech mouse.

OK, now it's clear that the assumption in comment #13 was wrong, keyboard and mouse worked well in the first stage installation. But after that, X11 proposal hasa been called...

Calling script x11_proposal MakeProposal
required X11 packages: []
x11 package status is: <true>
clients/x11_proposal.ycp:99 Loading library cache...
--- error ---
sh: socklist: command not found
ISaX: could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199.
--- error ---
clients/x11_proposal.ycp:105 Reading libsax cache data...
--- error ---
Argument "" isn't numeric in sprintf at /usr/share/YaST2/modules/XLib.pm line
261 (#1)
(W numeric) The indicated string was fed as an argument to an operator
that expected a numeric value instead.  If you're fortunate the message
will identify which operator was so unfortunate.
--- error ---
...
Calling script x11_proposal Write
required X11 packages: ["xorg-x11", "xorg-x11-server", "libusb", "sax2", "sax2-gui", "sax2-ident", "sax2-tools", "sax2-libsax", "sax2-libsax-perl"]
x11 package status is: <true>
Script x11_proposal returned $["success":true]

The problem is either in X11 configuration or Hwinfo:
Felix's system has one keyboard, one touchpad and one mouse but hwinfo found two keyboards and three mice. Reassigning to Snwint to check hwinfo again. Markus, see those errors in X11 configuration.

The kernel reports two keyboards (event2, event4) and three mice
(event1, event5, event7). Check /proc/bus/input/devices if you don't
believe me.

I any case, whatever the exact number really is, the bug report was about
a _missing_ keyboard section.

Sorry, no idea who to assign this to.

I see, if *missing* (or _missing_) then it's Marcus'...

Anyway, we should blame Kernel too...
(but after fixing X11 configuration)

Maybe I should mention that the xorg.conf used during installation
is not created by sax2 but by some scripts and commands which are part
of the yast2-installation package. I handed over my work in this area
to Arvin Schnell and as the reporter said it doesn't work for the first
phase of the installation process this is a problem in that code.

(In reply to comment #19 from Marcus Schaefer)
> Maybe I should mention that the xorg.conf used during installation
> is not created by sax2 but by some scripts and commands which are part
> of the yast2-installation package. I handed over my work in this area
> to Arvin Schnell and as the reporter said it doesn't work for the first
> phase of the installation process this is a problem in that code.
I am sorry but I do not see where I said that:

see comment #14:
> In the first phase of installation I did have keyboard and was able to enter
> user name and password for example.
>
> But my installed system (and the second phase of the installation) had the
> broken Xorg configuration.

Lukas got the situation totally right in comment #16:
> The problem is either in X11 configuration or Hwinfo:
> Felix's system has one keyboard, one touchpad and one mouse but hwinfo found
> two keyboards and three mice. Reassigning to Snwint to check hwinfo again.
> Markus, see those errors in X11 configuration.

Looking at my xorg.conf it looks to me like a fault of SaX:
> # /.../
> # SaX generated X11 config file
> # Created on: 2008-03-26T17:32:19+0100.
> #
> # Version: 8.1
> # Contact: Marcus Schaefer <sax@suse.de>, 2005
> # Contact: SaX-User list <https://lists.berlios.de/mailman/listinfo/sax-users>
> #
> # Automatically generated by [ISaX] (8.1)
> # PLEASE DO NOT EDIT THIS FILE!

you wrote:

> I did a fresh install on my MacBook today. I had severe problems with the
> bootloader therefore I am not sure whether I caused the problem.
> Nevertheless I think a system without keyboard is bad.

so your don't have a keyboard when you try to install the operating
system ? yes or no ?

if the kernel reports keyboards twice I don't see how I can help.

> so your don't have a keyboard when you try to install the operating
> system ? yes or no ?
It did work for the first part of the installation. After the reboot in the installation my keyboard was gone, because the xorg.conf did not have a kbd configured.

This is kind of strange. I thought that for the second part of installation the same xorg.conf (the scripted one) is used as for the first part. Only at the end of installation the (i)SaX based one is created for the installed system. Has this changed for openSUSE 11.0? Attached was xorg.conf created by (i)SaX for the installed system.

>This is kind of strange. I thought that for the second part of installation the
>same xorg.conf (the scripted one) is used as for the first part.

as far as I know this is correct but I'm not responsible for this anymore
Assigned to maintainer

Arvin, please figure out if for the second stage of installation a different xorg.conf than for the first stage is used. If yes, is it the iSaX generated one or do we even now have 3 different xorg.conf files? 2 different (script based) for the installation and one for the installed system, which is iSaX based?

The xorg.conf from comment #2 was generated by isax at the end
of the installation (second stage). Timestamp shows that. I don't
see why the problem with that xorg.conf can't be solved.

Otherwise AFAIK during second stage the same xorg.conf as during
first stage installation is used. But Alpha 3 is so broken that
this cannot be confirmed right now. Will have to wait for Beta 1.

Felix, can you please provide the file /etc/X11/xorg.conf.install?

Created attachment 206435 [details]
/etc/X11/xorg.conf.install

here it is.

Thanks, that one looks fine (has a keyboard section).

Felix, please copy xorg.conf.install to xorg.conf (after making
a backup) and restart the X server. Does the keyboard work then?
And please attach the X server log, /var/log/Xorg.0.log.

Created attachment 206439 [details]
/var/log/Xorg.0.log

this is he log of xorg.conf.install. It looks horrible as it is 1024x768 on a 1280x800 display. But the keyboard does work.

Looks good.

[...]
(II) LoadModule: "kbd"
(II) Loading /usr/lib/xorg/modules//input/kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.3.0
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 2.0
[...]
(**) Option "CoreKeyboard"
(**) Keyboard[0]: always reports core events
(**) Option "Protocol" "Standard"
(**) Keyboard[0]: Protocol: Standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xfree86"
(**) Keyboard[0]: XkbRules: "xfree86"
(**) Option "XkbModel" "pc104"
(**) Keyboard[0]: XkbModel: "pc104"
(**) Option "XkbLayout" "us"
(**) Keyboard[0]: XkbLayout: "us"
(**) Option "XkbKeycodes" "xfree86"
(**) Keyboard[0]: XkbKeycodes: "xfree86"
(**) Option "CustomKeycodes" "off"
(**) Keyboard[0]: CustomKeycodes disabled
[...]
(II) evaluating device (Keyboard[0])
(II) XINPUT: Adding extended input device "Keyboard[0]" (type: KEYBOARD)

So the configuration used for first and second stage of installation also works after installation. The remaining issue is, that ISaX at the end of installation creates a xorg.conf without keyboard driver section. Probably because hwinfo reports more than one keyboard and confuses SaX2 therefore. Reassigning again to Marcus.

It might be possible to reproduce this issue by connecting more than one keyboard to a machine. I didn't try this yet though.

What don't understand: Marcus, why would two keyboards be a problem?

Marcus, in case you don't have enough keyboards for testing at home, please let me know. Then I can setup a machine for you.

If I can provide anything just tell me...

Created attachment 209429 [details]
sax -r -m 0=intel

I can reproduce this on my running system with sax -r -m 0=intel. With 10.3 sax could successfully generate Xorg configs.

Sax put the following in the conf:
	Section "ServerLayout"
	  Identifier   "Layout[all]"
	  InputDevice  "Keyboard[0]" "CoreKeyboard"
	  InputDevice  "Mouse[1]" "CorePointer"
	  InputDevice  "Mouse[3]" "SendCoreEvents"
	  Screen       "Screen[0]"
	EndSection

But there is no Keyboard[0] defined in the conf, therefore Xorg, does not start:
	Data incomplete in file /tmp/sax2-11171/xorg.conf
	Undefined InputDevice "Keyboard[0]" referenced by ServerLayout "Layout[all]".
	(EE) Problem parsing the config file
	(EE) Error parsing the config file

*** Bug 382281 has been marked as a duplicate of this bug. ***

# sysp -q keyboard
Keyboard0 =>  XkbModel   : macintosh
Keyboard0 =>  XkbLayout  : de
Keyboard0 =>  XkbVariant : nodeadkeys
Keyboard0 =>  Name       : Apple Keyboard
Keyboard0 =>  VendorID   : 0x05ac
Keyboard0 =>  DeviceID   : 0x1000
Keyboard0 =>  Profile    : alps
Keyboard0 =>  RealDevice : /dev/input/event10

Keyboard1 =>  XkbModel   : macintosh
Keyboard1 =>  XkbLayout  : de
Keyboard1 =>  XkbVariant : nodeadkeys
Keyboard1 =>  Name       : Apple Internal Keyboard / Trackpad
Keyboard1 =>  VendorID   : 0x05ac
Keyboard1 =>  DeviceID   : 0x0218
Keyboard1 =>  Profile    : <undefined>
Keyboard1 =>  RealDevice : /dev/input/event7

This might be useful

*** Bug 250427 has been marked as a duplicate of this bug. ***

Looks like this issue cannot be reproduced with Beta2 when using a normal desktop machine with 2 keyboards (PS/2 + USB) connected.

*** Bug 388000 has been marked as a duplicate of this bug. ***

I am the reporter of bug 388000. I am not exactly sure if my issue is really a duplicate of this one as

1) I have no problems with no or too many detected input devices, just the keyboard type is wrong and

2) my bug report only covers the live-session before installation.

*** Bug 388003 has been marked as a duplicate of this bug. ***

Created attachment 214844 [details]
config of todays sax2

As sax2 had some things in the changelog I tried again today. But the problem is still the same:

Section "ServerLayout"
  Identifier   "Layout[all]"
  InputDevice  "Mouse[0]" "CoreKeyboard"
  InputDevice  "Mouse[1]" "CorePointer"
  InputDevice  "Mouse[3]" "SendCoreEvents"
  Option       "Clone" "off"
  Option       "Xinerama" "off"
  Screen       "Screen[0]"
EndSection

Is there anything I can provide?
I will be at LinuxTag in Berlin and could offer my MacBook for somebody to look into it.

I am at LinuxTag, does anybody want to have a look at the problem?

I just installed 11.0b3 today on my macbook and have the same issue. I'm escalating this to blocker because this should not happen in the final release and it does not appear to be receiving enough attention.

The problem is there are two keyboards detected, as we support only
one core keyboard sax will choose the first entry there. That's not
a problem but the entry selected also got a mouse profile assigned (alps)
which turns the keyboard into a mouse which ends up with no keyboard
which is bad.

I don't have such hardware here for testing which I think is required
to fix the bug. I think Stefan Dirsch can take care for that. 

I also think the problem is hwinfo which reports the same vendor
device ID's which we assign an alps touchpad for as keyboard 

Keyboard0 =>  Name       : Apple Keyboard
Keyboard0 =>  VendorID   : 0x05ac
Keyboard0 =>  DeviceID   : 0x1000
Keyboard0 =>  Profile    : alps

              ^^^^^^^^^^^^^^^^^^

              If this will not happen the problem will be fixed        

Hm, but it looks very convincingly like a keyboard.

Anyway, I can just blacklist the item, but I'll need someone to test
it and I'll need an ok from coolo whether this will make it into 11.0.

I'm willing and able to test any fixes.

[I've just copied the files to our server, might take some time until
they are visible to the outside]

Ok,

ftp://ftp.suse.com/pub/people/snwint/11.0/hwinfo-14.19-1.i586.rpm

is a new hwinfo. It should list only one keyboard. And sax2 should
be able to create a correct xorg.conf with it.

If you are testing RC1 and have a network connection, you can also check
if this works during installation using the driverupdate

ftp://ftp.suse.com/pub/people/snwint/11.0/dud_374101

For this, press F6 at the boot screen and enter the above URL
(and please watch linuxrc's messages if the update gets applied).

I just did a fresh net-install from the factory repo and it still doesn't detect my keyboard correctly. I hit F6 at the initial menu and entered the driver update url, but i'm not 100% sure if it worked correctly or not. I had to manually enter my IP address and when i was doing that, it asked for a URL which i left at the default. I was unsure if i needed to enter the one above at that stage or not. A message did pop up during the install saying that there were no updated drivers found.

So, how should i continue? Should i try a fresh re-install, or can i test stuff with this install? I don't particularly want to install again unless i have to.

I'm sorry, I don't have the faintest idea what you did. There's no place
where you'd need to enter your ip at all.

The basic idea is that you press F6, change the URL to the one above and
that's it. If you're unsure you can also download the driverupdate, put
it on, say, your local disk and point the URL to it ('disk:/wherever').

Note that linuxrc will print a message when it found the update (press
ESC early on to get rid of the splash screen).

I updated to your hwinfo:
# rpm -q --changelog hwinfo
* Do Mai 29 2008 snwint@suse.de
- fix macbook keyboard detection

* Mo Mai 26 2008 snwint@suse.de
- ppc: report usb controller properly (bnc #368234)

but it still does not work at all. I will attach the xorg.conf.

Created attachment 219098 [details]
sax xorg.conf with new hwinfo

I was doing a net install using this: http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/boot/boot.iso

For some reason DHCP wasn't working, so i had to manually enter my IP details so i could get network connectivity. Hope that makes it clearer, though it looks like felix definately did it correctly and it didn't fix the issue for him.

Ok, please run 'hwinfo --mouse --keyboard --log=foo' with the new hwinfo
and attach the log.

Created attachment 219154 [details]
hwinfo

Ok this is the output of hwinfo. I just updated my whole systems to todays factory, it was allready a week old.

Hm, please run getsysinfo and attach the tar this creates as well.

Created attachment 219164 [details]
getsysinfo

Ok, second try:

ftp://ftp.suse.com/pub/people/snwint/11.0/hwinfo-14.19-2.i586.rpm
ftp://ftp.suse.com/pub/people/snwint/11.0/dud_374101_b

Again, wait a bit for the sync to complete (and maybe check the changelog
to make sure you really got the new version).

Created attachment 219218 [details]
a working xorg.conf with newest hwinfo

thanks Steffen now it is working! I have at least a working keyboard.

I noticed that the syndaemon is not running automatically (is this a bug?).
Furthermore bug #250427 is still there, so I will reopen it.

The KDE4 RC1 32-bit live cd was a huge regression in terms of keyboard functionality for me. While beta 3 featured at least a partly working keyboard (meaning I could use most keys with alpha-numeric charactes) RC1 didn't provide me with a working keyboard at all under KDE. I did the following to try to fix this to no avail:

1) Used Qt Yast to set the correct keyboard profile (MacBook/MacBook Pro (Intl))
2) Switched to virtual console 1 (where the keyboard still works)
3) Switched to runlevel 1 to kill X
4) Switched back to runlevel 5 to restart X

I'll have to hope that the patch that didn't make it into RC1 will fix this problem but I'd really appreciate if an unscheduled RC2 could be released before the GM hits the servers.

FYI: 0x05ac/0x1000 may be a way to find out if you are on a MacBook,
but it is definitely _not_ the keyboard.

# lsusb
Bus 004 Device 002: ID 05ac:8240 Apple, Inc. IR Receiver [build-in]
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 004: ID 05ac:1000 Apple, Inc. Bluetooth HCI MacBookPro (HID mode)
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 05ac:021b Apple, Inc. Internal Keyboard/Trackpad
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 05ac:8300 Apple, Inc. Built-in iSight (no firmware loaded)
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I'd suspect that this will happen with more other devices.

The apple bluetooth receiver will report as keyboard and mouse
most likely because apple sells a bluetooth keyboard and mouse
as addons.

But since more bluetooth keyboards and mice are coming up, I'd assume
that other bluetooth dongles might act similarly.

I could even imagine some of the logitech cordless receivers do something
similar as they often work as interface for keyboard and mouse (and there
are some logitech mice/trackballs) that need a special profile as well
just like the macbook touchpad above.

Marcus (in view of comment 50) I think we might need a proper 
solution in the future.

Marcus, could we address this issue again for openSUSE 11.1/SLE11? 

As consequence of the possible non unique device ID matching in case
of USB devices I have talked with Stefan to find a solution for this
problem. Unfortunately it might be time consuming to implement and
maintain the suggestion but at least the result of the brain storming
should be available here:

* The idea is to have sub-vendor/device ID's as additional ID's
  provided along with the standard ID's

* The matching of vendor/device sub-vendor/device has to identify
  a device uniquely. A device which doesn't require a sub-vendor/device
  ID should provide the standard ID's as sub- ID's too

* The sub- ID's are self created ones and are the result of a detection
  magic which might be different for each device which we can't identify
  uniquely according to the provided ID's. I don't know if it is possible
  to identify a device uniquely according to other parameters than the
  ID's. We were thinking of the product name or other information provided
  by the device itself

The downside of all this is the non generic base. Each "problematic" device
needs some code to become identified and get a sub-ID pair assigned.

Just some thoughts

Marcus 

Thanks for the summary, Marcus. I think it's appropriate to keep this bugreport as enhancement. It's rather unlikely that we'll implement it, though.

Since synaptics is now loaded via HAL and no longer configured via profiles in xorg.conf, this should no longer be an issue. Fixed for Factory/openSUSE 11.2.