| bryceh | Sarvatt, hey did you get an arsenal script to search through Xorg.0.log files? | 01:11 |
|---|---|---|
| superm1 | Sarvatt, bug 537801 | 01:51 |
| ubottu | Launchpad bug 537801 in xf86-input-wacom "Touchscreen doesn't work after karmic->lucid upgrade" [Undecided,New] https://launchpad.net/bugs/537801 | 01:51 |
| superm1 | wait a minute, it asked me if i want to include my "sensitive" logs from gdm and then makes the bug public? | 01:51 |
| superm1 | that doesn't seem right | 01:51 |
| bryceh | superm1, it takes sudo privs to access them | 02:20 |
| bryceh | superm1, but we're not going to manually eyeball the gdm scripts to sanitize them of any sensitive info | 02:20 |
| bryceh | I'm not really even sure why they require su to look at them | 02:21 |
| superm1 | ah i see | 02:22 |
| Sarvatt | superm1: ohh boy.. | 02:38 |
| Sarvatt | that device actually has a proprietary blob driver not in ubuntu | 02:39 |
| Sarvatt | evtouch is whats supposed to support it for the basics, wacom is just taking control of it | 02:39 |
| Sarvatt | this is the driver for ubuntu btw - http://www.ideacom.com.tw/download/DRIVE/IDC_Linux_3_1_0.tar.gz | 02:44 |
| superm1 | Sarvatt, it worked without it though in karmic? | 02:44 |
| superm1 | so i guess evtouch was grabbing it in karmic then based on what you're saying | 02:48 |
| superm1 | but that appears to be in universe now in lucid? | 02:49 |
| Sarvatt | yeah, I'm really unsure of the status of evtouch in lucid, it doesn't even look to be functional with a udev xserver at first glance? | 02:51 |
| superm1 | it looks like it's depending on an old version of xserver-xorg-core | 02:51 |
| superm1 | unstable looks to have a patch for x server 1.7 | 02:58 |
| Sarvatt | http://packages.debian.org/squeeze/xserver-xorg-input-evtouch | 02:58 |
| Sarvatt | yeah | 02:58 |
| Sarvatt | bryce was looking into syncing it earlier | 02:58 |
| superm1 | so is our delta droppable then? | 02:58 |
| Sarvatt | the delta is all fdi files it looks like which are not functional anymore and need translating into udev rules, that's going to need some serious work | 03:04 |
| superm1 | is there a guide for doing that? | 03:07 |
| superm1 | looking at th existing rules, it seems a lot of them are just setting the x driver, not any bits | 03:08 |
| superm1 | oh synaptics seems to do options too | 03:09 |
| superm1 | oh but what a disgusting init script it had | 03:11 |
| superm1 | i am starting to think i dont want to commit to helping with this ;) | 03:11 |
| bryceh | yeah I put in a sync request on -evtouch yesterday. Waiting on an archive admin to flag it through | 03:12 |
| Sarvatt | need to be sure it'd actually even work before anyway, i'd start by grabbing the one from squeeze and adding your device to the udev rules it has to see if it even works | 03:12 |
| bryceh | I don't know if the current evtouch driver works, but it certainly doesn't build against xserver | 03:12 |
| bryceh | tjaalton didn't think the fdi's would need converted to udev | 03:13 |
| bryceh | however I wrote a page explaiing how to do this on the ubuntu-x wiki, in the input config section | 03:13 |
| Sarvatt | i need to find a really cheap evtouch device | 03:14 |
| superm1 | Sarvatt, http://configure.us.dell.com/dellstore/config.aspx?oc=blcwwfp&c=us&l=en&s=bsd&cs=04&kc=vostro-v13 | 03:15 |
| superm1 | that's what i have | 03:15 |
| Sarvatt | a bit out of my price range :) i think they sell cheapo usb digitizers people use to convert existing screens that work with evtouch though | 03:17 |
| Sarvatt | so we need a udev rule that sets the symlink, port all our hal matches and quirks to it, and figure out how to not have wacom interfere with it and vice versa because it seems wacom is loading for everything that matches ID_INPUT_TABLET | 03:37 |
| * Sarvatt wishes we had xorg.conf.d right about now | 03:37 | |
| bryceh | don't we? | 03:37 |
| Sarvatt | nope thats xserver 1.8 | 03:38 |
| bryceh | I think tjaalton backported it | 03:40 |
| bryceh | maybe I'm wrong | 03:41 |
| Sarvatt | he was playing with it but i'm not sure its something sane to backport especially this late, he had to remove the input abi bump in that came with it and remove ifdef's for the higher input abi so wacom would work with it and i have no idea if other drivers have similar things | 03:45 |
| Sarvatt | superm1: does your device work if you remove /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules ? | 03:49 |
| Sarvatt | packaging that blob ideacom driver seems like a good idea even if I just throw it in a PPA, asus and dell are both using that same device for their netbook touchscreens :D | 04:01 |
| superm1 | Sarvatt, it would be best to get it in restricted tbh | 04:04 |
| superm1 | Sarvatt, i just installed the debian package and things didn't work, i'll brb and try to remove that rule | 04:04 |
| superm1 | Sarvatt, well without that rule wacom doesn't load, but evtouch isn't loading either | 04:08 |
| superm1 | so i'm guessing it still needs some kind of udev rule | 04:08 |
| Sarvatt | yeah evdev should be taking it without the wacom rule, I was wondering if evdev was working with it | 04:09 |
| superm1 | http://pastebin.com/PCzdX3pV | 04:09 |
| Sarvatt | does that device show up in lsusb? | 04:13 |
| Sarvatt | if so can you pastebin lsusb -v? | 04:14 |
| superm1 | http://pastebin.com/hFry6d9y | 04:14 |
| superm1 | looks like yea | 04:15 |
| Sarvatt | superm1: maybe something like this as say /lib/udev/rules.d/67-xorg-evtouch.rules -- http://pastebin.com/0FmeGQpm | 04:50 |
| Sarvatt | or maybe just dropping lines 10-20 even if that doesn't work | 04:52 |
| tjaalton | superm1, Sarvatt: yeah wacom shouldn't be the "catch-all" tablet driver, but evdev | 04:59 |
| tjaalton | and xorg.conf.d doesn't really work for video drivers, because they need more than just the Driver section (in order to do fallbacks for instance) | 05:00 |
| tjaalton | superm1: so try to get evdev load, it should match evtouch in functionality | 05:01 |
| tjaalton | +to | 05:01 |
| superm1 | Sarvatt, that udev rule didn't do the trick | 05:05 |
| superm1 | nor with removing lines 15-20 | 05:05 |
| tjaalton | move the wacom rule away, does it load evdev then? | 05:07 |
| superm1 | i posted the pastebin above with wacom out of the way | 05:09 |
| superm1 | i'm a bit confused, it looked like it tried to load evdev for a joystick device | 05:09 |
| tjaalton | heh, yeah it needs a patch to only load for event* | 05:13 |
| tjaalton | type: MOUSE | 05:14 |
| tjaalton | so probably got it wrong then | 05:14 |
| Sarvatt | elographics seems to have fallen through the cracks too, lucid archive and debian git versions dont compile against xserver 1.7 | 05:24 |
| Sarvatt | luckily theres http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-elographics/elographics-1.2.3-abi.patch?view=markup | 05:25 |
| Sarvatt | same with mutouch http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-mutouch/mutouch-1.2.1-abi.patch?view=markup | 05:27 |
| tjaalton | luckily? those should just die :) | 05:28 |
| libv | tjaalton: about xorg.conf.d; it could've worked for graphics drivers | 06:47 |
| libv | but the modesetting model adopted for RandR1.2 lacked the expressivity to do this properly | 06:48 |
| libv | and now people are all on kms anyway, so there is no point going there (as "relevant" drivers will not go close anyway) | 06:49 |
| tjaalton | libv: ok | 08:16 |
| tjaalton | is the intel gpu lockup thingie a bit trigger happy perhaps? | 08:45 |
| tjaalton | intel has 50 more bugs than nvidia-180, 509 and counting :) | 08:46 |
| jcristau | bryceh: xserver -1u3 is not in git? | 14:31 |
| === yofel_ is now known as yofel | ||
| === radoe_ is now known as radoe | ||
| === Sinnerman is now known as Cobalt | ||
| unggnu | hi all | 17:19 |
| unggnu | I have some problems with font rendering and Intel since quite some time. Karmic is affected and Lucid too. It seems better since the 2.6.33 drm but lately I have seen it again. Some lines are just black or completly white and if I scroll them out of the view and back again they are fine. What's the best way to debug things like that? | 17:20 |
| unggnu | But there definately seem to be less corruptions than before 2.6.33 drm | 17:21 |
| unggnu | Or does it might also be a Firefox problem? | 17:21 |
| === Sinnerman is now known as Cobalt | ||
| unggnu | Btw. is the overlay support backported in the -intel driver for Lucid? | 17:23 |
| sebner | bryceh: around by any chance? | 20:27 |
| Sarvatt | hmm ${SHA1_LIB} was removed from XSERVER_SYS_LIBS in the newest xserver 1.7.5.902 ( http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.7-branch&id=ff5fb43a4b38c707a1a9948ace621a62b5b2457a ), our xkb cache patch isn't working now and looks related to that | 20:30 |
| Sarvatt | http://launchpadlibrarian.net/40884919/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.5.902~git20100312%2Bserver-1.7-branch.5a2b3f36-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz | 20:30 |
| bryceh | Sarvatt, hrm | 20:31 |
| bryceh | Sarvatt, was there a rationale for removing it? | 20:31 |
| tjaalton | looks like a mistake | 20:40 |
| bjsnider | ok, why is nvidia-current creating libvdpau_nvidia.so.1 as a link to the .so version? | 20:45 |
| bjsnider | my package creates the .so version as a link to the 19x.xx.xx file, which is the soname of the library. but why is a .so.1 link necessary too? | 20:48 |
| superm1 | bjsnider, probably want to raise that again whenever tseliot is in the room | 20:49 |
| bjsnider | why are the old packaging scripts set up to create the links in the .links files as well as manually in the rules file? | 20:51 |
| superm1 | They're old :) | 20:52 |
| tjaalton | looks like a mistake | 20:52 |
| tjaalton | (echo) | 20:52 |
| bjsnider | why isn't it sunny today... | 20:52 |
| bjsnider | ok, i'm going to retire from the question asking business | 20:52 |
| superm1 | haha | 20:52 |
| bjsnider | what i don't understand is, if a library has a soname of anything except 1, for example 52 like libavcodec, you have libavcodec.so.52 | 20:55 |
| bjsnider | then you have a link, libavcodec.so that points to it | 20:55 |
| bjsnider | i can understand that link | 20:55 |
| bjsnider | the linker doesn't know for sure what the soname is, so you need that generic link | 20:55 |
| bjsnider | but why create the .so.1 link? | 20:56 |
| bjsnider | everything seems to need a .so.1 link even if the soname isn't actually 1 | 20:56 |
| tjaalton | The run-time library package should include the symbolic link that ldconfig would create for the shared libraries. For example, the libgdbm3 package should include a symbolic link from /usr/lib/libgdbm.so.3 to libgdbm.so.3.0.0. This is needed so that the dynamic linker (for example ld.so or ld-linux.so.*) can find the library between the time that dpkg installs it and the time that ldconfig is run in the postinst script | 20:59 |
| tjaalton | from the debian policy | 21:00 |
| jarek | Who can build package with current openchrome trunk? It can resolve many bugs for via chips. | 21:01 |
| jarek | I can test it on my laptop | 21:02 |
| tjaalton | jarek: what about the version on debian? | 21:02 |
| tjaalton | it should be synced anyway | 21:02 |
| jarek | it's quite old for debian | 21:03 |
| jarek | So, I need to contact with debian devs? | 21:04 |
| tjaalton | huh, old? | 21:04 |
| jarek | without latest commits ;) | 21:04 |
| jarek | current svn is 840, but package is 812 | 21:06 |
| tjaalton | right | 21:06 |
| jarek | ther is patch witch can fix problem with resolution on my laptop | 21:07 |
| jarek | I want test it, but I am not familiar with compilation that kind of stuff | 21:08 |
| tjaalton | svn ftl | 21:10 |
| jarek | I must force myself to do this some day | 21:13 |
| jarek | currently I'm using windows on this old crap | 21:14 |
| jcristau | bjsnider: ld -lfoo looks for libfoo.so | 21:18 |
| jcristau | bjsnider: and produces a binary with a reference to libfoo.so.N | 21:18 |
| jcristau | bjsnider: so at runtime ld.so sees that reference and loads libfoo.so.N | 21:18 |
| tjaalton | jarek: what card/chip do you have? | 21:21 |
| bjsnider | jcristau, yes, that i understand perfectly. what i don't understand is creating the libfoo.so.1 link to libfoo.so.N | 21:23 |
| jcristau | eh, what? | 21:24 |
| jcristau | there's no .so.1 link | 21:24 |
| bjsnider | http://bazaar.launchpad.net/~albertomilone/nvidia-drivers-ubuntu/nvidia-current/annotate/head:/debian/nvidia-current.links.in | 21:25 |
| bjsnider | you can see them being created all over the place there | 21:26 |
| bjsnider | and they were in the previous packaging scripts too | 21:26 |
| jcristau | oh. nvidia. | 21:26 |
| jarek | It's unichrome pro, Fujitsu Amilo L7310W | 21:28 |
| jcristau | bjsnider: for libGL, its SONAME *is* libGL.so.1. the others i have no idea. | 21:28 |
| jarek | I'm not sure chipset name, can be CN400 or PM880 | 21:29 |
| bjsnider | jcristau, so perhaps this is some sort of bizarro nvidia quirk? | 21:29 |
| tjaalton | or just a packging goof | 21:31 |
| jcristau | bjsnider: anything related to nvidia is a bizarro quirk as far as i'm concerned :) | 21:31 |
| bjsnider | the libs in here are named like this: libnvidia-compiler.so.190.53 | 21:32 |
| bjsnider | so i don't see why a .so link to that isn't good enough | 21:32 |
| jcristau | did you check what the soname is? | 21:33 |
| bjsnider | that is the soname isn't it? | 21:33 |
| jcristau | ? | 21:33 |
| jcristau | how should i know | 21:33 |
| bjsnider | it's called 190.53 so isn't that the soname? | 21:33 |
| jcristau | no | 21:33 |
| bjsnider | i see | 21:34 |
| jcristau | the soname is in the elf header. it may be the same as the file name, or it may be different | 21:35 |
| bjsnider | how am i supposed to check that? | 21:36 |
| jcristau | objdump -p | 21:37 |
| bjsnider | jarek, there's another driver called unichrome that might work as well. the developer is in here | 21:38 |
| bjsnider | especially if your hardware is "old crap" as you put it | 21:38 |
| jarek | tjaalton: I googled for chipset name, and it saying PN800, but system information for windows showing pci names CN400/PM880 | 21:39 |
| jarek | bjsnider, my laptop isn't working like I expected a years ago, since then I tested livecd without succes | 21:44 |
| jarek | I can't do testing on working alerdy system | 21:45 |
| bjsnider | have you ever tried the unichrome driver? | 21:46 |
| bjsnider | jcristau, all of these sonames are 1, so perhaps the so.1 link is necessary for that reason? | 21:46 |
| jcristau | yes | 21:46 |
| jarek | I really don't remember, but I'm using older driver then openchrome, can be via or unichrome | 21:48 |
| bjsnider | you don't know what driver you're currently using? | 21:48 |
| jarek | currently my laptop is windows land | 21:49 |
| bjsnider | oh right | 21:49 |
| bjsnider | so it didn't work off the livecd | 21:50 |
| jarek | it's started with wrong resolution | 21:50 |
| bjsnider | libv, which driver would be best for this guy's hardware? | 21:50 |
| jarek | I see 1/4 of screen | 21:50 |
| bjsnider | that ain't good | 21:51 |
| jarek | It's known bug | 21:52 |
| jarek | but the cure is propably in current trunk on openchrome | 21:52 |
| jarek | I hope to test it on lucid prime time | 21:52 |
| bjsnider | luc might not be here at the present time | 21:53 |
| BUGabundo | bu noute | 21:56 |
| jarek | bjsnider: If it's too late for lucid, I will wait for daily 10.10 builds, hope my laptop will run without problems then | 21:58 |
| bjsnider | jarek, stick around in here until luc is here and then discuss it with him | 22:00 |
| jarek | ok, thanks | 22:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!