Viestit

1

Laitealue / Vs: Ubuntu ja HP Pavilion tx2020eo (tx2000, tx2020)

« : 26.06.08 - klo:09.15 »

Nyt meni mystiseksi. Lakkasi toimimasta koko kosketusnäyttö, kynällä tai ilman. Vaikea keksiä syitä, paitsi se unofficial patch, jolla suspend-ongelmaa korjasin. Ideoita mistä kohtaa ongelmaa voisi debugata?

You know that the touchscreen stops working after suspending, right? Restarting X restores functionality. I am working on a solution but so far it seems to be something that we will just have to wait out while they update the X-server to a yet unreleased version.

What happens is (not 100% on the details but the general idea is right) that when you suspend the kernel disconnects all USB devices including our wacom touchscreen and then it reconnects them all on resume, but X notices this and removes the input device and since X doesn't do hotplugging (it does but there are some quirks and most distros have it disabled) it won't reconnect it on resume. Thus we have no tablet on resume and a restart of X fixes it.

Edit: Wait, what patch? If it has done something to X and/or X input drivers you might have to reinstall your tablet drivers. /var/log/Xorg.0.log should tell you what has happened.

EditEdit: Thats what i get for writing posts before drinking my morning coffee.

2

Laitealue / Vs: Ubuntu ja HP Pavilion tx2020eo (tx2000, tx2020)

« : 25.06.08 - klo:16.08 »

Hello everyone, thought that I would chip in with parts of my xorg.conf since you were talking about the tablet.

Koodia: [Valitse]

Section "InputDevice"
    Identifier     "TabletStylus"
    Driver         "wacom"
    Option         "ForceDevice"   "ISDV4"
    Option         "Type"          "stylus"
    Option         "SendCoreEvents" "true"
    Option         "Device"        "/dev/input/by-path/pci-0000:00:0b.1-usb-0:2.3:1.0-wacom"
    Option         "Button2"       "3"  # make side-switch a right button
    Option         "TPCButton"     "on"
    Option         "TopX"          "218"
    Option         "TopY"          "100"
    Option         "BottomX"       "26235"
    Option         "BottomY"       "16400"
EndSection

Section "InputDevice"
    Identifier     "TabletTouch"
    Driver         "wacom"
    Option         "ForceDevice"   "ISDV4"
    Option         "Type"          "stylus"
    Option         "SendCoreEvents" "true"
    Option         "Device"        "/dev/input/by-path/pci-0000:00:0b.1-usb-0:2.3:1.1-wacom"
    Option         "TopX"          "1180"
    Option         "TopY"          "900"
    Option         "BottomX"       "25500"
    Option         "BottomY"       "15620"
EndSection

Section "InputDevice"
    Identifier     "TabletEraser"
    Driver         "wacom"
    Option         "ForceDevice"   "ISDV4"
    Option         "Type"          "eraser"
    Option         "SendCoreEvents" "true"
    Option         "Device"        "/dev/input/by-path/pci-0000:00:0b.1-usb-0:2.3:1.0-wacom"
    Option         "TopX"          "404"
    Option         "TopY"          "150"
    Option         "BottomX"       "26090"
    Option         "BottomY"       "16334"
EndSection


I have renamed my devices to be easier to identify when configuring them in GIMP for example, I have also calibrated them to be more exact.

As for what I have been working on lately it is getting input hotplugging to work, I have it working with USB mice, keyboard and the synaptics tablet so those can be removed from the static xorg.conf, I am still working on the wacom devices but it seems that it will be an ugly hack until we get an X.org server newer than 1.4.2, the patches needed to enable full input hotplugging for all devices got added to the X.org GIT 5 days ago, so hopefully they will make it to 1.4.3 or 1.5 whichever happens first.

3

Laitealue / Vs: Ubuntu ja HP Pavilion tx2020eo (tx2000, tx2020)

« : 24.06.08 - klo:12.17 »

Mr. Ahlskog: Did you do something to get that omnibook/hp script to run automatically on boot? What was your way to do it? Did you use inits or let gnome to take care of it? Just out of curiosity and maybe to find best way for guide...

Funny thing, my keys have kept working through suspends and reboots, haven't booted windows so that might reset it. Guess I spoke too soon if I indicated that it needed to be run on every boot. So for me it has been a one time deal, but i am keeping the script around incase it resets at some point.

4

Laitealue / Vs: Ubuntu ja HP Pavilion tx2020eo (tx2000, tx2020)

« : 18.06.08 - klo:13.25 »

I am happy to report / On ilo ja kunnia kertoa / that adding those kernel parameters to Ubuntu as well / että näiden lisääminen Ubuntunkin kernel-parametreiksi / fixed the suspend on my machine / saivat SUSPENDIN TOIMIMAAN!

Pikku juttuhan tuo on, mutta 20 eri combon yrityksen jälkeen aika mukavaa. Eiköhän tällä Linuxilla pärjäillä.

Good to hear, odd that Ubuntu worked without those parameters, during my tests the machine would randomly reboot without those params.

5

Laitealue / Vs: Ubuntu ja HP Pavilion tx2020eo (tx2000, tx2020)

« : 17.06.08 - klo:09.35 »

Kokeilin myös Lennyn beta 2:ta. 50% käynnistyksistä jumiutui ainakin minun tx2020eo:llani johonkin jota väitti laitteistoviaksi, mahdollisesti kelloa synkatessa. En taida tutkia Debian-vaihtoehtoa enempää.

Might want to try passing "noapic nolapic irqfixup" to the kernel, I have needed it on every 64bit distro i have tried on this machine including Gentoo 2008.0_beta2 minimal cd and OpenSuse 10.3 DVD, the 2005.0 minimal x86 cd however behaved properly without those flags.

6

Laitealue / Vs: Ubuntu ja HP Pavilion tx2020eo (tx2000, tx2020)

« : 13.06.08 - klo:12.34 »

Did it work out of the box, or did you do something to get it working?

Out of the box, so if you have some extra space you can always try it.

7

Laitealue / Vs: Ubuntu ja HP Pavilion tx2020eo (tx2000, tx2020)

« : 13.06.08 - klo:09.13 »

Tyyppiviaksi väittäisin, kun kerran itsekkään en ole tuosta selvää saanut. Muutaman viikon annoin jo koko asian olla. Vika on siis mitä ilmeisimmin se, että näytönohjainta ei saa hereille suspendin/nukkumisen jälkeen.

Gentoon wikissä on ohjeita ja selityksiä, miksei acpi toimi linuxissa niinkuin pitäisi. Niistä ei valitettavasti juurikaan ole ubuntun peruskäyttäjälle apua. -> http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
Sivun selityksestä sain sen verran tollkua, että kyseessä on buginen DSTD. Ja arvatenkin sourceforgen dstd:n linux kehittäjillä ei ole valmista pakettia tx2000 sarjan laitteille. tx1000 löytyy kyllä. http://acpi.sourceforge.net/dsdt/view.php

Jos joku minua viisaampi saisi tuon ohjeistuksen avulla tehtyä jotakin ohjetta aiheesta ubuntulle, niin olisin suunnattoman kiitollinen. Tai mikäli tietää moisen olemassaolosta, ja kertoisi sen meille, niin sekään ei olisi väärin.

Luulisin, että tämä ongelma saattaisi koskea nykymuodossaan kaikkia hp:n kannettavia, joissa on nvidia geforce go 6150 näytönohjain. Jos jollakulla on tietoa moisesta, niin kertokoon ihmeessä...

You know, that is really odd. Mine has suspended and resumed perfectly from the start, well nearly perfectly USB disconnects causes X to discard the tablet as inputdevice until restart of X. But then again i run Debian Lenny on it so it looks to be distro specific.

8

Laitealue / Vs: Ubuntu ja HP Pavilion tx2020eo (tx2000, tx2020)

« : 11.06.08 - klo:10.18 »

2nd update for the day 

I found something, something good
http://sourceforge.net/projects/omke/
Download and unpack omke-1.0, its a perl script. Then run it with omke.pl -k 1, or without params for help
after running it with -k 1 the "refresh" and "dvd" buttons on the remote start working, also all the buttons start working in tablet mode
So now we are left with only two dead buttons, the rotate and quicklaunch.

Great progress for one day.

Edit: needs to be run as root btw, or sudo for you ubuntuers

9

Laitealue / Vs: Ubuntu ja HP Pavilion tx2020eo (tx2000, tx2020)

« : 11.06.08 - klo:09.02 »

Update, installed vista to do some testing.

Findings: keyboard, remote and those buttons on the edge of the screen are killed by something way low level, because they do it in linux, windows, grub and bios setup. However once installing the HP driver pack they start working with the lid closed. So reverse engineering is required since i doubt we can get any information out of HP

Also HP has released some bios updates, dunno if they do any good

Second update, nvidia has released driver 173.xx.xx which resolves issues with mobile gpus and standby

10

Laitealue / Vs: Ubuntu ja HP Pavillion tx2020eo (tx2000, tx2020)

« : 20.05.08 - klo:22.28 »

So we have same problems with waking the screen up. My "bubblegum"-repair was to disable "blank screen" option from battery preferences and doing changes that i told about in first post. That way the display goes black when closing the lid, and picture comes back when opening it. As i stated earlier, this method doesn't turn off power from GPU, but still uses less battery when lid is closed. And i'm planning to use this configuration until i find out better solution.

Do you have your wacom working with touchscreen? Do your changes apply to this? Stylus/pen works fine with my confs, but used with finger i'm not even close.

And thanks again.

+m

What i found out while fighting with the tablet/touch is that the devicenodes are all but straightforward, /dev/input/wacom is pretty much randomly assigned and all the neccessary links did not show up in /dev/input/by-id/* so i used the ones in /dev/input/by-path/ they seem to be more persistent, there will be two ending in -wacom and one is for the pen and one is for touch.

wacdump can help you identify which is which as long as they are not being used by X.

Koodia: [Valitse]

Section "InputDevice"
    Identifier     "TabletStylus"
    Driver         "wacom"
    Option         "ForceDevice"   "ISDV4"
    Option         "Type"          "stylus"
    Option         "SendCoreEvents" "true"
    Option         "Device"        "/dev/input/by-path/pci-0000:00:0b.1-usb-0:2.3:1.0-wacom"
    Option         "Button2"       "3"  # make side-switch a right button
    Option         "TopX"          "218"
    Option         "TopY"          "234"
    Option         "BottomX"       "26235"
    Option         "BottomY"       "16349"
EndSection

Section "InputDevice"
    Identifier     "TabletEraser"
    Driver         "wacom"
    Option         "ForceDevice"   "ISDV4"
    Option         "Type"          "eraser"
    Option         "SendCoreEvents" "true"
    Option         "Device"        "/dev/input/by-path/pci-0000:00:0b.1-usb-0:2.3:1.0-wacom"
    Option         "TopX"          "404"
    Option         "TopY"          "401"
    Option         "BottomX"       "26090"
    Option         "BottomY"       "16334"
EndSection

Section "InputDevice"
    Identifier     "TabletTouch"
    Driver         "wacom"
    Option         "ForceDevice"   "ISDV4"
    Option         "Type"          "stylus"
    Option         "SendCoreEvents" "true"
    Option         "Device"        "/dev/input/by-path/pci-0000:00:0b.1-usb-0:2.3:1.1-wacom"
    Option         "TopX"          "1180"
    Option         "TopY"          "900"
    Option         "BottomX"       "25287"
    Option         "BottomY"       "15617"

And a late entry, my Debian install seems to have had a habit of wearing out the harddrive by constantly parking it after being idle for 10 seconds so take care that you are not killing your disk by over-aggressive powermanagement.

Edit: I will include my xorg.conf, nothing secret in that anyways, ignore the top x,y bottom x,y, just been trying to improve calibration

11

Laitealue / Vs: Ubuntu ja HP Pavillion tx2020eo (tx2000, tx2020)

« : 20.05.08 - klo:14.21 »

Ok. Just wasn't sure if you did understand finnish at all. And i think that my answer was not hostile in any way. If i made it seem that way, i'm terribly sorry. That was not my intension.

So. After you turn your display to tablet-mode all keys stop working? I guess that this is hardware/firmware problem that (as you suggested) points to kernel. This should be posted as a bug.

Do they start working again after you turn your display back to normal mode?

Personally i haven't found any real use for buttons in tablet-mode. So personally i'm more interested in getting other stuff work. But anyway, you're right. It doesn't act like it does under windows. And it would be a good thing to get everything working 100%. For all tx2xxx users.

One way to see what's happening when lid is in tablet mode, is to put on another display, and run another tty in it.

I'm not any wizard with linux, as i'm just passing on things i found out myself configuring this machine. Had only about two years of experience as home user.

My only problem at the moment is that display does not wake up after suspend, like all other devices do. After killing x server with ctrl-alt-backspace, it gives display back. And that minor issue with lightscribe and 64bit system.

Did suspend really work out of the box for you?

I'm just guessing, but do you speak swedish as your mother-language? If you do, please consider translating my main post for swedish forum? We might all get some help from there on various issues. I'm planning to translate it to english as soon as have time and interest.. or the article gets finished.

Main thing is that i personally can't offer real help on this issue about buttons dying in tablet-mode. However, i'm meeting my *NIX guru M.Kulma today, and i'll discuss about this issue with him as well.

Thank you for participating. I wasn't even aware of that issue before. I just thought that buttons are not intented to work in tablet-mode. I didn't even test remote with tablet-mode though...

Yours, Miro from Turku/Åbo

Well, i didn't know your intentions and sometimes its better just to get it out quickly, no hard feelings.

The lockout or what it is of the keyboard happens in the last cm or two from closing the lid in either tablet or normal way, and yes they return as soon as you lift it above that limit.

Suspend worked out of the box on Debian lenny with 2.6.24-1-amd64 SMP kernel.

However allowing the display to go into powersave will make it black and not return until restart of X, also i have the same issue when switching to a terminal. Probably some powersave/video options that i just have wrong.

I will try translating into swedish and add some (debian specific?) changes that i had to make to get the tablet working

12

Laitealue / Vs: Ubuntu ja HP Pavillion tx2020eo (tx2000, tx2020)

« : 20.05.08 - klo:09.20 »

Which buttons are we talking about? do you mean those on the lid? (rotate, settings, quickplay, dvd) Or do you mean the whole keyboard?

I've seen somewhat same results when i'm trying to suspend. But that's just because X doesn't wake up after rest of the machine wakes from suspend.

From those settings and rotate buttons i couldn't get keycodes at all, but dvd and quickplay work fine.

If it's the whole keyboard that gets stuck on your machine, i think there's something really wrong... On my machine, normally it's only display that doesn't wake up after suspend. If you don't need suspend or you can replace it with hibernation for a while, that might do the trick. At least until i or someone figures out how to make suspend working corectly.

Muuten. Englanniksi laitteesta on oma threadi ubuntun kansainvälisellä foorumilla. Tämä ongelma varmaankin kannattaisi kertoa myös sinne.
http://ubuntuforums.org/showthread.php?t=708726&page=9
Threadin laite on muuten täsmälleen sama, mutta ns. jenkkiversio.

Kyllä mä nyt ymmärrään suomea, on vaan sen kirjoittaminen mitä vaivaa.

Anyways, seems i was pretty unspecific earlier, the rotate and settings buttons dont seem to generate any keycodes, nor any events on any device recognized as evdev by the kernel. But the dvd and quickplay buttons work after xmodmapping them, same with the sleep and lock keys on the fn-f# buttons.

What i noticed was that when you close the lid either in tablet mode those keys stop working as per what you said, but also that the remote stopped working, and because all those things map through the keyboard i had an idea and decided to test it. I did as so, i closed the lid almost completely, i barely managed to squeeze a finger in there to press a key on the keyboard and at the same time as the dvd&quickplay buttons stopped working the keyboard stopped giving input too. Now that sounds like there is a signal somewhere telling that lid closed and then the kernel or whatever decides that "hey we dont need that internal keyboard anymore" and kills it.

Also for the record, suspend to ram works fine for me, only thing is that on return usb-devices arent enumerated before Xorg tries them and the wacom stops working until restart of X.

Now you can tell me to get out, or we can try to get this thing working 100%

Greetings from Vaasa

13

Laitealue / Vs: Ubuntu ja HP Pavillion tx2020eo (tx2000, tx2020)

« : 19.05.08 - klo:14.12 »

Thanks for a great guide, got my tx2020eo on friday and got rid of Vista immediately.

The buttons stop working because something (Xorg perhaps) kills the keyboard when you close the lid, this needs to be investigated.
For the other two buttons i have not yet found anything but worst case scenario is a kernel driver.

Korjaan, its not Xorg more like kernel or even worse bios but we would need to crossreference with windows.