Bug 369801

Does going back to the previous kernel fix the problem?

(In reply to comment #1)
> Does going back to the previous kernel fix the problem?
> 

I removed 2.6.23.1-10, but I still have 2.6.22.9-91 installed. The tablet works
fine when I boot into that version. Do you want me to explicitly test on
2.6.23.1-10 again or is it sufficient to know that my tablet at the moment still
works when I boot into 2.6.22.9-91 and fails when I boot into 2.6.23.1-21?

2.6.22.9-91 did not have kernel support for those devices. It looks like maybe
adding support made them stop working??

(In reply to comment #3)
> 2.6.22.9-91 did not have kernel support for those devices. It looks like maybe
> adding support made them stop working??
> 

I just reinstalled 2.6.23.1-10 to check your hypothesis.
In 2.6.23.1-10 the tablet is working fine.

Could you possibly try some of these other kernels to see where the problem
starts?

-17
http://koji.fedoraproject.org/koji/buildinfo?buildID=22895

-19
http://koji.fedoraproject.org/koji/buildinfo?buildID=22976

-20
http://koji.fedoraproject.org/koji/buildinfo?buildID=23094

Sander, do you have to touch the tablet with the pen to work in 2.6.23-1-10?
The question is because that's how a tablet will behave in X if there's no proper
kernel and X tablet drivers loaded.

Also, what is in the file /etc/X11/xorg.conf ?

Also, please attach here:
    /proc/bus/input/devices
    /etc/X11/xorg.conf
    /var/log/Xorg.0.log
    ls -l /dev/input/*

(In reply to comment #6)
> Sander, do you have to touch the tablet with the pen to work in 2.6.23-1-10?
> The question is because that's how a tablet will behave in X if there's no
> proper kernel and X tablet drivers loaded.

Sorry, I don't understand the question. Do you mean that I have to test if the
tablet works when the pen is close to the screen instead of touching it? Or do
you mean that I should try to move the cursor by touching the screen with my
finger instead of the pen? Or do you mean something else?

Created attachment 252201 [details]
/proc/bus/input/devices

Created attachment 252211 [details]
/etc/X11/xorg.conf

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

Created attachment 252231 [details]
ls -l /dev/input/*

(In reply to comment #8)
> Also, please attach here:
>     /proc/bus/input/devices
>     /etc/X11/xorg.conf
>     /var/log/Xorg.0.log
>     ls -l /dev/input/*
> 

I've done this for 2.6.23.1-10, do you want it for 2.6.23.1-21 as well?

(In reply to comment #14)
> I've done this for 2.6.23.1-10, do you want it for 2.6.23.1-21 as well?
> 

Yes, that would be helpful too.

> Sorry, I don't understand the question. Do you mean that I have to test if the
> tablet works when the pen is close to the screen instead of touching it? Or do
> you mean that I should try to move the cursor by touching the screen with my
> finger instead of the pen? Or do you mean something else?
tablets usually have proximity information, so you don't need to touch the
tablet with the pen to make the pointer move. Can you move the pointer using the
pen without touching the screen with the pen?

hm. it's a serial based tablet and it will use only userlevel, Xorg, driver.
Unless the serial port support is broken, the kernel shouldn't be the culprit.
Also, forget about the proximity question: it happens only for USB tablets.
Chuck, any relevant serial/tty changes between those versions?

> tablets usually have proximity information, so you don't need to touch the
> tablet with the pen to make the pointer move. Can you move the pointer using the
> pen without touching the screen with the pen?

Yes, I can. If the pen comes closer to the screen than about 1 cm, the pointer
starts moving.

(In reply to comment #5)
> Could you possibly try some of these other kernels to see where the problem
> starts?
> 
> -17
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22895
> 
> -19
> http://koji.fedoraproject.org/koji/buildinfo?buildID=22976
> 
> -20
> http://koji.fedoraproject.org/koji/buildinfo?buildID=23094
> 

None of these work :(

Created attachment 252481 [details]
/proc/bus/input/devices 2.6.23.1-21

Created attachment 252491 [details]
ls -l /dev/input/* 2.6.23.1-21

Created attachment 252501 [details]
/var/log/Xorg.0.log 2.6.23.1-21

(In reply to comment #17)
> hm. it's a serial based tablet and it will use only userlevel, Xorg, driver.
> Unless the serial port support is broken, the kernel shouldn't be the culprit.
> Also, forget about the proximity question: it happens only for USB tablets.
> Chuck, any relevant serial/tty changes between those versions?
> 

I just realized I never explicitly tested if it is the wacom that actually makes
X fail. So, I commented out the wacom related parts of xorg.conf to make sure.
Now, 2.6.23.1-21 boots fine (but without tablet functionality of course). So,
indeed the wacom breaks X as I assumed before.

Can you upload /var/log/dmesg after booting each kernel?

Created attachment 253601 [details]
/var/log/dmesg 2.6.23.1-10

Created attachment 253611 [details]
/var/log/dmesg 2.6.23.1-21

Do you want dmesg from the intermediate kernel versions as well?

Can you try changing xorg.conf to use /dev/ttyS1 fot the tablet?

(In reply to comment #28)
> Can you try changing xorg.conf to use /dev/ttyS1 fot the tablet?

Yes, this did the trick. I now have a working tablet in 2.6.23.1-21.
Thanks!

Closing as "notabug."

There is still a problem here. Booting my laptop from the docking station
results in /dev/ttyS1 being assigned to my tablet. Booting it standalone results
in /dev/ttyS0 being assigned to my tablet. This is not very convenient, since
/etc/X11/xorg.conf configuration must be changed to accommodate for this. Can
the assignment of /dev/ttyS# be made consistent? Should I put in a separate
feature request for this?

does the ttyS1 appears when you boot without the docking?

(In reply to comment #33)
> does the ttyS1 appears when you boot without the docking?

Do you mean in /dev? In that case yes:

[localhost ~]# ls -l /dev/ttyS*
crw-rw---- 1 root uucp 4, 64 2007-11-16 17:07 /dev/ttyS0
crw-rw---- 1 root uucp 4, 65 2007-11-16 18:06 /dev/ttyS1
crw-rw---- 1 root uucp 4, 66 2007-11-16 18:06 /dev/ttyS2
crw-rw---- 1 root uucp 4, 67 2007-11-16 18:06 /dev/ttyS3
[localhost ~]# 

No, check doing:
   dmesg | grep ttyS

and will output something like:
   00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
   00:0c: ttyS1 at I/O 0x200 (irq = 5) is a NS16550A

I want to know if the ttyS1 line appears

(In reply to comment #35)
> No, check doing:
>    dmesg | grep ttyS
> 
> and will output something like:
>    00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>    00:0c: ttyS1 at I/O 0x200 (irq = 5) is a NS16550A
> 
> I want to know if the ttyS1 line appears

This is the output:

[localhost ~]# dmesg|grep ttyS
00:0a: ttyS0 at I/O 0x200 (irq = 5) is a NS16550A
[localhost ~]# 

So no ttyS1...

OK, so what happened was: the kernel didn't supported the dock until the newer
version. And once the dock was identified, it detects another serial port that
is actually the old one.
I have another question: with and without the docking do you use the same
connector for the serial port?

> I have another question: with and without the docking do you use the same
> connector for the serial port?

What do you mean with connector? It is a tablet notebook, so the tablet is
integrated into the screen.

duh, forgot about this.
OK, fill another BZ# describing that a different serial port appears when you're
using the dock and the former doesn't works.

(In reply to comment #39)
> duh, forgot about this.
> OK, fill another BZ# describing that a different serial port appears when you're
> using the dock and the former doesn't works.
> 

Done, see:
https://bugzilla.redhat.com/show_bug.cgi?id=387551