| superm1 | Sarvatt, if just dropping the .id's should fix it, i'll test without it in place. bryce: canonical should have this hardware available already to debug with. | 06:47 |
|---|---|---|
| tjaalton | Sarvatt: do we still have to change the defaults if those are going to be easily configurable? | 07:11 |
| Sarvatt | it should just work with no nv.ids, the primary video device in his xorg.0.log is the 9400M G which isnt supported and is getting matched to -nv because the first card's id matches.. its just whats going to happen with a generic xorg.conf i'm not sure of | 07:43 |
| Sarvatt | no xorg.conf -nv is just going to say no so vesa uses it since it'll go through the list of nv vesa then fbdev | 07:45 |
| Sarvatt | i guess it probably will still need the server patch with a generic xorg.conf, nv is going to match from the 10DE catchall and it looks like it only gets 1 try with it there? luckily its just 084x and 086x nvidia device id's that need special handling unless we go nouveau, then we'd need to add those early nvidia cards too | 08:09 |
| tjaalton | Sarvatt: was one of those replies for me?-) I was talking about synaptics :) | 08:39 |
| Sarvatt | oh! | 08:39 |
| tjaalton | whee, mesa 7.5~rc4-1 in experimental | 08:40 |
| Sarvatt | sorry, i was confused by what you meant by easily configurable :D | 08:40 |
| Sarvatt | should have figured you didnt mean the -nv problem | 08:40 |
| tjaalton | heh | 08:40 |
| Sarvatt | well, i imagine so because xubuntu and kubuntu arent going to have g-s-d to configure it? | 08:41 |
| tjaalton | I'd have thought kde at least had something similar | 08:42 |
| tjaalton | since you can configure *everything* there | 08:42 |
| tjaalton | :) | 08:42 |
| Sarvatt | they do, its called konsole but typing synclient TapButton1=1 is too tough ;D | 08:43 |
| tjaalton | lunch-> | 08:43 |
| Sarvatt | oo, did it get released or still unreleased? regarding mesa 7.5 | 08:46 |
| Sarvatt | nevermind, i can look :D | 08:47 |
| tjaalton | Sarvatt: the package is now in experimental, and available for merging | 09:41 |
| tseliot | Sarvatt, tjaalton: my daemon will handle touchpads. I only need to write a UI | 09:42 |
| tseliot | s/will handle/handles/ | 09:43 |
| Sarvatt | whats the daemon for? | 09:43 |
| tseliot | Sarvatt: it can load your settings at startup (with a configuration file), it allows to set touchpad (and other input) properties from any language which has dbus bindings. It also allows you to disable the touchpad while you're typing, etc. | 09:48 |
| tseliot | I'll blog about it soon | 09:48 |
| tjaalton | tseliot: isn't it duplicating effort with g-s-d? | 09:50 |
| tseliot | tjaalton: I don't think so. g-s-d is just for GNOME while my daemon can be used in KDE or in any other DE | 09:51 |
| tjaalton | but if g-s-d will have the same functionality? | 09:52 |
| tjaalton | or mostly the same | 09:52 |
| tjaalton | and it's already running on every gnome desktop | 09:52 |
| tseliot | from what I have seen, it doesn't | 09:52 |
| Sarvatt | it does, just needs to be updated to 2.27.4 | 09:52 |
| === baptiste_ is now known as baptiste | ||
| tseliot | Sarvatt: do you have a link to this? | 09:53 |
| Sarvatt | http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=4eb9bd09219afbb56f114a2d10bc585e24db803e | 09:53 |
| tseliot | from what I can see they need a function for each property | 09:54 |
| tseliot | while my daemon doesn't. You simply pass it the property and a list of values and that's it | 09:54 |
| tseliot | g-s-d deal with a limited set of properties | 09:55 |
| tseliot | deals | 09:55 |
| tseliot | thanks to my daemon we can have access to any property | 09:56 |
| Sarvatt | have you seen that things dont use SHMConfig anymore and everything is runtime configurable with synclient or input device properties now? | 09:58 |
| tjaalton | how do you determine if it should be running or not? | 09:58 |
| tseliot | Sarvatt: I use XInput. No shared memory is involved | 10:00 |
| tseliot | tjaalton: ? | 10:01 |
| tseliot | it won't be installed by default | 10:01 |
| tjaalton | ah | 10:02 |
| tjaalton | iow it will be temporary until the native configuration tools do the same :) | 10:02 |
| tseliot | they would have to rewrite their current system. But yes, it could happen. What I want is a unified system which we can use in any DE. Each DE should have its own frontend but rely on the same backend | 10:04 |
| tjaalton | it's still yet-another-daemon for a single type of hardware | 10:04 |
| tseliot | wrong. The frontend will be specific to touchpads while the daemon can deal with any kind of input device which supports XInput | 10:05 |
| tjaalton | ok, better :) | 10:05 |
| tjaalton | so the ui could be the *DE:s native capplet | 10:06 |
| tjaalton | which then would start the daemon if the defaults have been changed | 10:07 |
| Sarvatt | ahh ok, i was having problems wrapping my head around why you might want to daemonize something that could be done just once at startup and directly at runtime if something needed to be changed | 10:08 |
| tseliot | yes, native applets could be written | 10:09 |
| Sarvatt | (synclient, syndaemon) | 10:09 |
| tseliot | the daemon does all the work while other applications (or even scripts) can connect to it through dbus to do, for example, what synclient and syndaemon do | 10:11 |
| tseliot | it catches events | 10:11 |
| tseliot | so that when you unplug a device you can get a signal and, for example, refresh the list of devices in a UI, etc. | 10:12 |
| tseliot | or applies the saved settings to the new device | 10:12 |
| tseliot | nothing's set in stone yet though. | 10:13 |
| Sarvatt | are there any drawbacks to using the secondary slots allocated for driver detection in xserver? i just made a patch making the first slot default to vesa for 084x and 086x (unsupported 8xxx and 9xxx IGP chipsets) and nv otherwise, but i was thinking that maybe we could add nouveau in the first slot and move the vesa/nv choice down to the second since nouveau isnt installed by default. i know it wouldnt be a problem with no xorg.conf bu | 10:43 |
| Sarvatt | t i'm unsure with the default xorg.conf what would happen | 10:43 |
| Sarvatt | it'll just fail to load nouveau that doesnt exist with no xorg.conf, thats what happens for me with no i810 driver on intel | 10:44 |
| Sarvatt | we dont have openchrome autodetection support in karmic's xserver but we have the driver, that'd be useful to add | 10:46 |
| Sarvatt | thats the next pci id in line after nvidia and before rendition in xf86AutoConfig.c from git master | 10:47 |
| Sarvatt | guess i should try building it with nouveau in the first slot and see what happens with the default xorg.conf since i cant follow the source well enough | 10:48 |
| tjaalton | is it the fedora nouveau patch? | 10:50 |
| tjaalton | http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.6.1-nouveau.patch?revision=1.1&view=markup | 10:50 |
| Sarvatt | kind of, i ripped it out of that since we dont need the detection for the early cards since -nv supports it | 10:50 |
| tjaalton | but AIUI we are going to change to nouveau.. | 10:51 |
| Sarvatt | i was thinking about having driverList[0] = "nouveau"; and driverList[1] = "nv"; | 10:51 |
| Sarvatt | with no xorg.conf it'll just skip nouveau if it isnt installed | 10:51 |
| Sarvatt | but it'd open up the option of having nouveau without explicitly setting it in xorg.conf | 10:52 |
| tjaalton | that's the way it's supposed to be done | 10:53 |
| tjaalton | patching the server | 10:53 |
| tjaalton | because once the xorg merge is uploaded, new installations don't have xorg.conf anymore | 10:53 |
| * Sarvatt cant wait for that | 10:54 | |
| tjaalton | I should probably open a bug about defaulting to nouveau, if there isn't one already | 10:54 |
| Sarvatt | so much easier to patch it in here than hunt down how every driver pulls ids | 10:54 |
| tjaalton | it concerns xorg, xserver and the kernel | 10:54 |
| tjaalton | yeah, forget the ids files | 10:55 |
| Sarvatt | if it was up to me i'd make all 10DE default to vesa and opt in ranges for -nv, who doesnt use nvidia binary drivers? :D | 10:58 |
| tjaalton | livecd users :) | 10:59 |
| Sarvatt | i'm guessing the default device in the default xorg.conf precludes it from using anything but driverList[0], doesnt seem like it tries the rest of the list like it does with no xorg.conf | 11:02 |
| tjaalton | it's a completely different codepath | 11:03 |
| tjaalton | it doesn't even generate the list | 11:03 |
| tjaalton | see the file where the functions are called from | 11:03 |
| Sarvatt | wow, no wonder xorg.conf needs to go looking at this | 11:16 |
| Sarvatt | guess a patch for superm1's bug wont be so easy after all unless it does | 11:17 |
| tjaalton | the ids patch should be dropped, and xorg.conf removed | 11:18 |
| * Sarvatt wonders how many little hidden places are making sure theres an xorg.conf like the livecd-rootfs thing | 11:18 | |
| tjaalton | that's enough | 11:18 |
| Sarvatt | well he'd still need a patch making it drop 086x to vesa instead of nv still after that | 11:18 |
| tjaalton | yeah, that | 11:19 |
| Sarvatt | silly hybrids | 11:19 |
| Sarvatt | at least there arent many nvidia/nvidia ones out there and all are using 086x, it shouldnt have his problem if its intel/nvidia or intel/ati because of the 170_primary_pci_device.patch forcing it to use the card on the bus the system is using at boot time as the primary one | 11:22 |
| Sarvatt | if i were him i would just make it use the dedicated video always in bios or something instead of being stuck on the IGP always like he is now | 11:25 |
| Sarvatt | and it would solve that problem because it would hook the video bios up to the 9400M so it would use the -nv supported driver | 11:27 |
| Sarvatt | if linux didnt report being vista to acpi i would say it'd probably be a good idea for them to add a check on which card to use to the dsdt if osvendor matches linux | 11:29 |
| Sarvatt | cant imagine many people want to buy a laptop with a fast GPU and be stuck only using the crappier IGP if they use linux because its not going to support switching in userland anytime soon | 11:31 |
| Sarvatt | lol that is exactly what some other vendors do | 11:49 |
| Sarvatt | sony ones default to the dedicated video if acpi_osi doesnt match vista | 11:50 |
| Sarvatt | of course you have to boot with acpi_osi="!Windows 2006" for that to kick in.. | 11:51 |
| Sarvatt | those are intel/nvidia hybrids though | 11:52 |
| tjaalton | according to the spec we are not going to change to nouveau without kms, and since it's not stable yet it's deferred | 12:28 |
| tjaalton | and our nouveau version is still over two months old | 12:29 |
| tjaalton | wonder if a newer version would've helpe | 12:29 |
| tjaalton | d | 12:29 |
| Sarvatt | theres a kms enabled nouveau-kernel-source and xserver-xorg-video-nouveau on edgers and nouveau edgers thanks to RAOF | 12:46 |
| tjaalton | it's newer than the one in karmic? | 12:47 |
| === mvo__ is now known as mvo | ||
| tjaalton | hmm, the latest mesa change added dri.pc, but in the wrong package | 12:55 |
| tjaalton | the changelog entry would suggest that it was meant for libgl1-mesa-dev as in debian, but it was added to mesa-common-dev | 12:56 |
| jcristau | mesa-common-dev is possibly more appropriate | 12:56 |
| tjaalton | o | 12:57 |
| tjaalton | k | 12:57 |
| tjaalton | I'll leave it there then :) | 12:58 |
| jcristau | feel free to move it in the debian branch | 12:59 |
| tjaalton | sure | 12:59 |
| tjaalton | wait, debian ships it in libgl1-mesa-dev, ubuntu in mesa-common-dev, but it's not guaranteed to be the same on every arch since it's generated during build? | 13:03 |
| tjaalton | so isn't libgl1-mesa-dev the best place then? | 13:03 |
| jcristau | hrm. | 13:07 |
| tjaalton | if it's going to be made arch specific | 13:07 |
| jcristau | i guess that was the reason i put it there | 13:07 |
| jcristau | but i can't think of a reason it would be arch specific | 13:07 |
| tjaalton | true | 13:08 |
| tjaalton | all the variables should be the same on every arch | 13:08 |
| tjaalton | it'll need a Replaces too? | 13:18 |
| jcristau | yup | 13:19 |
| tjaalton | done | 13:24 |
| tjaalton | and pushed | 13:24 |
| jcristau | thanks | 13:24 |
| tjaalton | thanks for doing the upload to experimental, it's now ready for karmic | 13:25 |
| Sarvatt | tjaalton: hopefully it wont fail building on amd64 90% of the time like it does on PPAs in karmic :D | 15:53 |
| Sarvatt | heres a log of a failed one, it'll build right on a retry usually though.. never fails locally or built under a jaunty PPA https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+build/1095892/+files/buildlog_ubuntu-karmic-amd64.mesa_7.6.0~git20090626.f57280cc-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz | 15:55 |
| tjaalton | so it's the glu_mangle.h error | 15:59 |
| jcristau | looks like it gets installed from both swx11+glu and swx11+glu-static | 16:01 |
| Sarvatt | the file it fails on changes every time, that and gl.pc are where it fails more often than not though | 16:01 |
| jcristau | easiest way to fix it is disable parallel builds | 16:05 |
| Sarvatt | seems like the builds are fine parallel but the installs are racy, but i dont know how to disable the parallel installs without seperating each packages install in rules | 16:07 |
| Sarvatt | heyo tormod! | 16:10 |
| tormod | hi Sarvatt! | 16:10 |
| jcristau | Sarvatt: something like http://paste.debian.net/40563/? | 16:13 |
| jcristau | need to make sure it fails if one of the targets fails, but. | 16:13 |
| Sarvatt | i will try that right now and upload it to 4 PPAs to see if it fails on any, thanks jcristau | 16:17 |
| Sarvatt | ack tjaalton updated origin/ubuntu, need to refresh hooks again | 16:18 |
| Sarvatt | nice, no hooks needed now actually | 16:20 |
| Sarvatt | hmm tormod, auto-xorg-git doesnt work with the mesa version in origin/ubuntu now :D | 16:38 |
| Sarvatt | oh he left | 16:38 |
| Sarvatt | ah its because of the package name | 16:40 |
| Sarvatt | has a space in front of it by mistake | 16:40 |
| popey | I just got a friend of mine to file bug 393510 which is a quite spectacular xorg crash when he touches the mouse touchpad. Any suggestions on where to look for more info would be appreciated. | 16:41 |
| ubottu | Launchpad bug 393510 in xorg "X crashes when I touch the mouse pad" [Undecided,New] https://launchpad.net/bugs/393510 | 16:41 |
| jcristau | Sarvatt: fixed | 16:43 |
| Sarvatt | wow, thanks again jcristau! | 16:43 |
| Sarvatt | uploaded it to 4 PPAs, it really is a 90%+ FTBS on amd64 so for sure i'll see if its fixed by the install rules change | 16:52 |
| Sarvatt | jcristau: the server in sid is exposing dri2 extension version 1.1.0 and the intel 2.7.1 release version doesnt understand that so its still trying to use the old i830DRI2CreateBuffers and i830DestroyBuffers which have been replaced from what I can see? -- http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?h=2.7&id=5ea315944ada3097fe33a14e0c1bdf1268be0308 | 17:35 |
| * Sarvatt installs 2.7.1 release to see if i get the same problem | 17:54 | |
| Sarvatt | i cant even get 2.7.1 release version to work at all on xserver master/dri2proto 2.1 | 18:20 |
| tjaalton | Sarvatt: heh, the changelog bug was a copypaste error.. damn meld doesn't show the arrows anymore, some gtk bug I guess | 18:37 |
| === Duke`_ is now known as Duke` | ||
| Sarvatt | Duke`: did you see idr's reply on dri-devel? got some code you want me to test on 7.6? | 19:26 |
| Duke` | yes I've seen | 19:26 |
| Duke` | I'll fill a bug report | 19:27 |
| Duke` | but now I'm eating :p | 19:27 |
| Duke` | Sarvatt: I posted my bug report: https://bugs.freedesktop.org/show_bug.cgi?id=22540 | 20:34 |
| ubottu | Freedesktop bug 22540 in Drivers/DRI/i915 "VBO is still mapped after drawing, therefore glMapBuffer fails" [Normal,New] | 20:34 |
| Sarvatt | what the heck is going on with this fglrx-installer in x-updates.. i think bryce might have ended up binary copying it because the orig.tar.gz's dont match | 20:35 |
| Sarvatt | okie, i'll check it out Duke` | 20:35 |
| Sarvatt | yep same error for me on mesa 7.6 | 20:49 |
| Sarvatt | Before copying data, buffer is mapped | 20:51 |
| Sarvatt | Mapping frame 2 | 20:51 |
| Sarvatt | Mesa: User error: GL_INVALID_OPERATION in glMapBufferARB(already mapped) | 20:51 |
| Sarvatt | Segmentation fault | 20:51 |
| bryce | erf, sorry yeah I did just binary copy it | 20:57 |
| bryce | I built it in my own ppa and then copied it over; I assumed that'd be equivalent to posting it there directly | 20:57 |
| bryce | what might be a problem is that I had packaged fglrx-installer myself and posted it for people to test, but meanwhile superm1 also packaged it, and uploaded to ubuntu directly | 20:58 |
| bryce | so the packages I did conflict with superm1's due to differing orig.tar.gz's | 20:59 |
| superm1 | bryce, oh what i put into the archive actually had support for 2.6.30 | 20:59 |
| bryce | really, my packages should be dropped in favor of new backports of superm1's package | 20:59 |
| superm1 | bunch of hacked up patches that I gathered on the internets to make it work | 21:00 |
| bryce | cool | 21:08 |
| bryce | superm1, I never did figure out how to order the 10v with ubuntu with EPP. I ended up just ordering the 10v without the discount. | 21:09 |
| superm1 | bryce, oh well. I sent a website bug about the fact that it wasn't showing up on the normal 10 and 10v pages, and it's been assigned, so it should be sorted out somehow | 21:10 |
| superm1 | you might be able to call and get your discount still | 21:10 |
| bryce | it's only $28 so hardly worth the effort, but I might raise it with our program rep on our end; seems weird that it's harder to get the employee discount on stuff running our own software. | 21:14 |
| bryce | maybe there's some switch they can flip or something | 21:15 |
| superm1 | hopefully | 21:16 |
| Sarvatt | Duke`: well your gl demo runs fine on i915simple gallium at least | 22:13 |
| tormod | I am trying stock karmic (believe me) and glxgears is transparent (on radeon RV410), anyone seen this? | 22:13 |
| Duke` | Sarvatt: maybe, but it's totally different code I think | 22:14 |
| Sarvatt | yep it is, just trying other things out :) | 22:14 |
| Duke` | :) | 22:15 |
| Duke` | I wonder if it is related to bug f.d.o #22428 | 22:15 |
| Sarvatt | phew everything is fugly under gallium, textures missing even on the simplest of demos | 22:16 |
| Sarvatt | thats the commit i linked isnt it | 22:17 |
| Duke` | yeah I think | 22:17 |
| Sarvatt | xdemos/glxcontexts runs fine for me | 22:18 |
| Sarvatt | i'm on an aspire one like the original report person is too | 22:20 |
| tjaalton | bryce: so, xorg and mesa.. could those be uploaded soonish? | 22:21 |
| bryce | sure, do you want to upload or would you prefer me to do it? | 22:22 |
| Sarvatt | it actually requires dri2proto 2.1 now btw, wont even be able to build it until you bring that over | 22:30 |
| bryce | yeah I'll file a sync request for that | 22:31 |
| Sarvatt | https://bugs.edge.launchpad.net/bugs/391005 | 22:34 |
| ubottu | Ubuntu bug 391005 in x11proto-dri2 "[Sync Request] Please sync x11proto-dri2 (2.1-1) from Debian [unstable] (main)" [Wishlist,Confirmed] | 22:34 |
| tjaalton | bryce: I can do those tomorrow | 22:35 |
| bryce | tjaalton, sounds good | 22:35 |
| bryce | Sarvatt, huh, wonder why that hasn't gone in | 22:36 |
| Sarvatt | intels the only driver that will need a rebuild after updating x11proto-dri2 at least | 22:36 |
| bryce | Sarvatt, but only after also updating xorg-server, right? | 22:37 |
| Sarvatt | yeah | 22:37 |
| bryce | yeah so it's pretty traditional to do a mass-rebuild of drivers following the xserver update | 22:38 |
| bryce | in fact I think tjaalton has a handy dandy script for doing it | 22:38 |
| Sarvatt | only other thing that uses it is ati KMS | 22:38 |
| bryce | Sarvatt, I bumped the dri2proto syncreq and subbed pitti, so hopefully that should accelerate it a bit | 22:41 |
| tjaalton | yeah I have a crude script to do that | 22:53 |
| Sarvatt | jcristau: thanks again for the help, breaking up the install in debian/rules for mesa did fix it | 22:57 |
| Sarvatt | forgot a ; though, i was slow and uploaded it without that and it took 4 hours for it to build for me to notice :D http://pastebin.com/m433e64d5 | 22:59 |
| Sarvatt | it built on 4 PPAs without any problems vs the 90% failure rate on karmic amd64 normally | 23:01 |
| lesshaste | I was about to upgrade from intrepid to jaunty when it told me there is no fglrx driver for jaunty... what is the situation there? | 23:02 |
| Sarvatt | fglrx doesnt support anything under hd 2xxx anymore | 23:02 |
| lesshaste | Sarvatt: sorry what is hd 2xxx? | 23:03 |
| lesshaste | and does this mean no accelerated 3d in jaunty for my graphics chip? | 23:04 |
| Sarvatt | ati HD 2000 series | 23:04 |
| lesshaste | oh so mine is just the rs480 onboard graphics chipset | 23:04 |
| Sarvatt | you use xserver-xorg-video-ati now combined with mesa for 3d | 23:06 |
| Sarvatt | the binary driver doesnt support your card anymore | 23:06 |
| lesshaste | is this the same as the radeon open source driver? | 23:08 |
| Sarvatt | yep | 23:08 |
| lesshaste | ok.. that's not as bad as it was right? The specs got released.. or something like that :) | 23:09 |
| Sarvatt | it has come a long way since intrepid | 23:09 |
| lesshaste | ah.. radeonhd is not the same as radeon :) | 23:13 |
| lesshaste | I am slowly catching up | 23:13 |
| Sarvatt | i put a patch here with proper whitespace incase you guys want to use it, its from jcristau and fixes the ftbs with mesa in karmic on PPAs (and probably in the archive) http://sarvatt.com/downloads/mesa_build.patch | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!