bryycetjaalton, I see there's some xorg-server changes queued in git; is there a reason they're not uploaded yet?00:53
=== Sarvatt_ is now known as Sarvatt
Sarvattlooks like xf86-input-wacom moved to sourceforge git now - http://sourceforge.net/mailarchive/forum.php?thread_name=20100106065734.GA20435%40barra.bne.redhat.com&forum_name=linuxwacom-devel01:43
Sarvatti cant work out the udev rules/xorg.conf entries to get it working for the life of me but people have it working fine with hal even with input abi 9 :(01:44
SarvattI dont get it but I'm not getting the batchbuffer IO errors with 2.4.17 and mesa 7.7, I must have just been hitting an error that was in 2.4.16 and fixed before 2.4.17 when I was crashing with 2.9.1 before. 02:04
Sarvattother people in that bug were saying they didnt get it with 2.9.1 so I guess its something in the newer ddx making it need the older libdrm not to crash02:05
Sarvatti need it to crash now that i've got a kernel with the better batchbuffer dump built in that ickle was asking for so i'm going back to edgers, no crash with x-testing packages since they were uploaded though02:08
bryyceSarvatt, excellent02:09
bryycesounds like libdrm/mesa can be uploaded now02:10
bryyceI'll touch base with timo tomorrow to see if there's anything else to do before uploading (and see if he wants to do it or if I should)02:10
Sarvatti was thinking about it, and is intel 2.10 a good idea for the LTS really? I still see quite alot of bugs with people not able to use KMS, just worried about dropping UMS support entirely02:12
Sarvattthats painful to say because I love my crack versions :D02:12
bryycethere's pros and cons, I don't have a solid opinion02:13
afvhi. is anyone using nouveau?02:15
RAOFWell, not right now, but yes in general.02:15
afvi installed it today02:16
afvand i'm having this issue with fonts:02:16
* RAOF is no longer sure how appropriate “nouveau by default" in lucid will be.02:16
Sarvatti'm also kind of questioning dropping hal for udev as custom patches that are really different than upstream, and doesnt seem like the whole udev/inputclass stuff will be up to snuff until xserver 1.9 since its in feature freeze now and tseliots changes for udev tags might not make it until then? seems like we're going to need xorg.conf.d for wacom but I probably dont understand the whole situation. i'm not sure if the xorg.conf.d stuff is even02:16
Sarvatt backportable since it bumps the input abi 2 times over 1.702:16
RAOFafv: When you say "installed", what do you mean exactly? :)02:17
afvi'm using lucid with 2.6.3302:18
afvand using xorg edgers ppa02:18
RAOFAnd what card?  Have you installed the nouveau-firmware package (if you've got a geforce 8 or above?)02:18
Sarvattyeah nouveau really seems lucid+1 too, would be so much easier when its in the actual kernel and it's still so volatile02:19
afvit's installed02:19
bryyceSarvatt, yeah I had a bad feeling about dropping hal, and it seems my worry was justified02:19
afv01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)02:19
afvasus laptop02:19
RAOFSarvatt: Yeah; I'm not confident that we'll be able to do any backporting of kernel fixes, and even their DDX work is more xserver 1.8 focused.02:21
RAOFAlso, it seems no one in the kernel team is tasked with actually driving it :)02:23
bjsniderafv, where did you get the .33 kernel?02:23
afvform http://kernel.ubuntu.com/~kernel-ppa/mainline02:23
RAOFIf you've got the DDX from xorg-edgers then you've also got nouveau-kernel-source, so it doesn't really matter.02:24
bjsniderRAOF, what do you mean abou the remark about nouveau by default on lucid?02:24
RAOFbjsnider: I'm no longer convinced that it is a good idea.02:25
bjsnidersurely you can't think the nv ddriver is a better idea...02:25
SarvattI really do at least02:25
RAOFThe nv driver doesn't require a kernel module that it will be really difficult to backport fixes to.02:26
bjsniderevery day there are people who come into +1 and complain that nv has given them a glorious black screen02:26
RAOFIt would be lovely to give users a non-crap nvidia driver by default, but if we're assuming that they're using the open driver as a stepping-stone to the binary driver, then I don't think nouveau-by-default buys us much except backporting headaches.02:27
Sarvattpersonally I'd rather vesa be the default over -nv, just need a screen to be able to install the blob through the gui :D02:27
bjsnideryou mean in the sense that you're not going to be using the .33 kernel?02:27
RAOFbjsnider: Right.  But more than that, I don't think using the .33 kernel would buy us much, either; nouveau will continue to be developed against drm-next.02:28
RAOFIt'd make the lucid release easier, but in a year's time that's not going to be very relevant.02:28
RAOFSarvatt: Is there any hardware that nv drives that vesa doesn't?  That's a nice thought :)02:29
Sarvattand supporting it in a LTS would be a nightmare with how much it changes on a week to week basis02:29
afvRAOF, yes, i do have the nouveau-kernel-source installed02:29
Sarvattvesa works on igp's! :D02:29
bjsniderthen don't change it02:29
bjsniderjust get a decent build in there and freeze it like that02:29
RAOFbjsnider: We can't drop nouveau into main and then not support it.  That's the whole point of main!02:29
bjsniderwell, then explain to me how fedora is able to get around these issues02:30
Sarvattthe changes are going to be too major to backport upstream fixes at some point02:30
RAOFBy not supporting it.02:30
Sarvattthey haven't used nouveau in RHEL?02:30
RAOFI don't think so, no.02:31
RAOFI could be wrong here, but that would seem crazy.02:31
bjsniderbut you can't be expected to fix bugs that are not fixed upstream02:32
bryyceif lucid is to go by, we'd probably only actively do support/backports to it for a month or so after release02:32
Sarvattyeah thats what I mean by fedora doesn't, fedora doesnt support nouveau for long outside of making people update to new releases :D02:32
RAOFI guess it would work if they paid darktama to backport all the fixes to whatever kernel/libdrm/Xserver versions RHEL uses.02:32
bryycefor lucid, after alpha-1 we generally only did security fixes and a few random targets of opportunity02:32
RAOFbryyce: By "lucid", you mean... Karmic?  Hardy?02:33
Sarvattya mean hardy bryyce?02:33
bryyceah right, hardy02:33
bryyceanyway, I suspect what we (you guys and me) will want to do is put driver updates into a ppa for users that need them02:34
bryyceespecially with nouveau that'll be a lot less trouble than doing a lot of backporting02:34
bryyceand I definitely agree that being aggressive about using vesa whereever we're uncertain about nouveau is a dandy idea02:35
bryyceopen to suggestions on that02:35
bjsnidervesa will probably give you a broken screen resolution02:35
RAOF...until you install the binary driver.02:35
bryycebjsnider, yeah but who cares, the user will just use it as a bridge to -nvidia02:36
RAOFWhich is what we're targetting here.02:36
bjsniderwhat about old junk pre-geforce 6k? they can't use the blob02:36
bryycewith -nv they're not getting 3D, which these days is becoming more and more a requirement02:36
RAOFMan, I hope we'll be able to turn on nouveau gallium by 10.10; gnome-shell will be an unhappy camper with nv.02:37
bryycebjsnider, well it's not like we'll be deleting -nv, just wouldn't have it as the default02:37
RAOFbjsnider: They install one of the *many* legacy versions of nvidia-glx?02:37
RAOFWe haven't dropped any of our 4 nvidia-glx packages, have we?02:37
bryycenot afaik02:38
bjsnideri haven't checked02:38
bjsniderdo they work with the newer x servers?02:38
RAOFFair point.02:38
bjsnideror kernels02:38
bjsniderhas anybody tested that?02:38
RAOFafv: I'm about to upload a new nouveau-kernel-source; feel free to try with that.02:38
bryycethey are usually brought up to date for newer xservers and kernel02:39
bjsnideryes but the 177 for instance wouldn't have been touched for aloooong time now02:39
bryyceNvidia tests, and I've been working with our QA team to get test procedures in place for the binary drivers02:39
Sarvattall but the 96.xx series were updated for xserver 1.702:39
bryyceI think the oldest legacy driver may not have been rebuilt02:39
Sarvatt96.xx is geforce 2 and older i think02:40
bryyceretaining -nv for just those oldest ones might make sense02:40
afvRAOF, sure, i'll try it. thanks. :)  i'm going also to upgrade from .33 rc2 to rc302:40
RAOFSo the cards that the binary driver doesn't work on are also the cards that nouveau has the worst performance on.  Sweet.02:41
bryycebut it would be nice if we could stop putting attention on -nv and just focus efforts to supporting -nouveau02:41
bjsnidernouveau will get you x-video and stuff like that on an old riva tnt2, and you can't use any of the 177 or later blobs, and there are other showstoppers on the 96/71 blobs02:41
bjsnidersince nvidia spends a total of 5 minutes a year working on them02:41
bjsniderand nv02:41
RAOFafv: Kernel upgrades probably won't do much for nouveau; nouveau-kernel-source replaces all the drm infrastructure anyway.02:41
afvok :)02:41
RAOFbjsnider: If we really wanted to use novueau as a feature-driver we'd need to make sure it's not slower than vesa on those cards.02:42
bjsnidera feature driver? is that what vesa is?02:43
afvRAOF, and what about 3d? is the guide at http://nouveau.freedesktop.org/wiki/GalliumHowto ok to follow?02:43
RAOFafv: Yeah.  You should get a not-too-shabby compiz experience, if my 7600go is any indication.02:44
afvi tried that today02:45
Sarvattnv is great for those, its just igp's, newer cards and those hybrid graphics laptops that really melt down with nv from what i've seen02:45
RAOFbjsnider: You're suggesting that we use nouveau on the really old cards because nouveau supports interesting features, but on really old cards there's the problem that the acceleration setup time exceeds the actual acceleration, so the driver is slower than no acceleration.02:45
bjsniderRAOF, the gnome-shell guys told me in their channel that gnome-panel is not in fact being removed as an option in gnome-3, so don't worry about gallium by 10.1002:45
Sarvattand some agp-pci-e bridge chip nvidia cards02:45
afvbut there's a "gmake" at the page that i didn't use :s02:45
afvwhere's gmake from?02:45
afvi get a "No command 'gmake' found, did you mean:"02:45
Sarvatti really hope to have nouveau gallium packaged in edgers by the time lucid releases, its really nice even now02:46
afvthat would be really nice02:46
RAOFSarvatt: Apart from the kernel panics, of course.02:46
Sarvattyeah, i saw alot of commits supposedly fixing gpu hangs under 3d to nouveau a few days ago, at least for nv5002:47
bjsniderRAOF, there are a couple of people over in +1 that have riva tnt2 cards i think. perhaps they know already if nouveau is fast enough02:48
RAOFbjsnider: Yes.  DanaG is one of them, and he complains that it's much slower than no acceleration.02:49
Sarvattcant imagine using nouveau on one of those, pixmaps + 16mb vram fun02:49
afvam i supposed to run glxgears using "$ LD_LIBRARY_PATH="/home/afv/.temp/nouveau/mesa/lib/" LIBGL_DRIVERS_PATH="/home/afv/.temp/nouveau/mesa/lib/gallium" glxgears"?02:50
afvfor example02:50
RAOFafv: Yeah.  I tend to just export those variables and run stuff normally, though.02:50
afvok. but then i get a "Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable02:50
Sarvattyup that looks right, i just set up a bash alias for it -- alias gallium='LD_LIBRARY_PATH="/opt/mesa/lib/" LIBGL_DRIVERS_PATH="/opt/mesa/lib/gallium"'02:51
Sarvattdo you have LIBGL_DEBUG=1 set afv?02:51
Sarvattshould only see that if you do02:51
RAOFFor what it's worth, that guide is a bit old, and doesn't use the same set of configure flags that I use, but looks right.02:51
bryyceI gather the main thing that is behind the push for nouveau is to get Ubuntu able to do KMS and show the fancy boot stuff across all the major gfx cards out of the box02:51
afvrunning glxgears: http://pastebin.com/d461e9adf02:52
afvSarvatt, hmm, i don't think so :s02:52
bryycebut if we are not confident that nouveau is solid enough for Lucid, then I'd be willing to try pushing back on it.  But we'd really need to make a convincing case02:53
RAOFAs long as no one wants to actually support it with bug fixes, I think it'll be fine.02:53
bryyceyeah like I said, I think most realistically we'll just point people to PPAs02:54
RAOFAs a piece of snapshot code right now, I think it's a better default nvidia driver than nv.02:55
bryyceI could see us pushing backports for a few weeks post-release for any critical issues while it's still reasonably easy to backport stuff02:55
Sarvattstill too quirky on my nv86 for me to say that :(02:55
bjsniderkms isn't only for boot02:55
bjsniderit also does fast vt switching02:55
Sarvattwould want to isolate the chips that only work with KMS with nouveau as well, I havent seen a list yet but mine is one of them02:56
bryycebjsnider, yeah I know but that isn't a feature that many beyond us geeks care about ;-)02:56
RAOFYes, but that's a bit irrelevant for nvidia; the binary blob doesn't (and won't, I think) do kms, what we're really trying to support is "nice initial boot until you install the blob"02:57
bjsnidergeeks bite the heads off chickens in a circus02:57
bryycenerds are sour candy that comes in a little box02:57
RAOFBecause people, quite reasonably, want 3D.  And we *definitely* aren't going to ship that :).02:57
bjsniderbryyce, well played, number six.02:58
Sarvattif this was a normal release I would for sure be pushing for it but it being a LTS... I'm happy to use a PPA :D02:58
RAOFI've never heard "geek" used in that fashion; in all the usages I've seen, “geek" is not pajoritive.02:58
RAOFWheras “nerd" is.  Anyway...02:58
bryyceand biting heads off chickens is cool02:59
bryyceRAOF, I'll make a note to doublecheck with the kernel team about nouveau, either tomorrow or early next week02:59
RAOFOk.  Thanks.03:00
RAOFI'm not sure how I can be helpful there at the moment :)03:00
Sarvatti've got my bets on 2.6.34-rc2 being out before lucid :D03:01
bryycecould be03:01
Sarvattand fixes needed for nouveau not being easily backportable to 2.6.3203:02
bryyceit's kind of funny (or sad), prior to UDS everyone was saying, "Let's be conservative about what we change in Lucid so we can really make what we have solid"03:02
bryyceand then at UDS, day by day we got more and more X changes set as requirements... dropping HAL, nouveau, changing to the new wacom driver, etc.03:03
RAOFAnd now it's all like “nouveau!  kms! puppies!"?03:03
bryyceI found it quite frustrating03:04
Sarvatti'm surprised how cracky its being in some areas (like the extreme boot speed aggressiveness causing other problems) and conservative in others (like the kernel version)03:04
RAOFafv: nouveau-kernel-source uploaded; give it half an hour or so and it should be available for you.03:05
Sarvattif we had 4 months i can see it but i was under the assumption things were going to freeze alot earlier03:05
Sarvatthalf hour?! ppa builds got faster, had to wait 10 hours for the last round of ddx builds03:06
bryycethe boot guys really drove hard for a lot of changes that I personally think are biting off a lot to chew03:06
Sarvattoh i think you built a gallium debug module afv03:06
Sarvatti dont get messages like that03:06
bjsnideris the kernel team happy with the idea of using the .32 kernel again?03:07
bryycebjsnider, the ones I talked to seemed enthusiastic about it03:07
RAOFIt's going to be an lts kernel release, isn't it?  And IIRC RedHat will be using it, and suse, so we'll be in good company there.03:10
afvhmm, Sarvatt, anyway i can't run compiz..03:15
Sarvattdo packages in backports build against other components in backports? because you can almost bet there will be libdrm updates needed to build new nouveau in backports03:15
afvRAOF, thanks!03:15
Sarvattafv I use ./configure --enable-glx-tls --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests03:16
RAOFafv: Does compiz segfault?03:16
Sarvattbut i think the configure options have changed since the last time i built it03:16
Sarvattbeen alot of change in gallium configure flags in mesa master in the past few weeks03:16
RAOFBecause that's what it was doing for me most recently :)03:16
afvnop. i get some weird stuff (like a white but transparent layer over the screen. lol)03:17
afvSarvatt, thanks, i'll use that03:17
Sarvatti think that wiki page had you compile in debug03:17
afvcompiz: http://pastebin.com/d328aeba103:19
Sarvattoh nice they updated the wiki03:19
afvSarvatt, hmm, maybe, it does have a "--enable-debug"03:19
Sarvattyou can ignore the libtxc_dxtn.so error though, everyone gets that if they dont have it installed and use debug03:21
Sarvattguess i'll package up this libkms next time i update libdrm in edgers03:23
afvok :)03:25
bjsniderRAOF, do you know of nouveau has the same power-management issue that radeon has with the kms driver? where the card is constantly at full-throttle?03:26
afv"Preparing to replace nouveau-kernel-source 0.0.15+git20091231-0~10.04~ppa1 (using nouveau-kernel-source_0.0.15+git20100108-0~10.04~ppa1_all.deb) ..."03:27
RAOFbjsnider: I haven't noticed it; I seem to get approximately the same (crappy) battery life with nouveau as nvidia.03:28
SarvattI get ALOT less battery life with nouveau, its always running at full clock speed on my 8400M GS03:30
afvbrb. i hope :p03:30
Sarvattlike 40 minutes vs 1 hour 50 minutes03:30
RAOFIt's possible that my 7600 just doesn't have any appreciable throttling.03:30
Sarvattyeah mine has 3 power states and its usually at 120mhz with the blob03:31
RAOFMaybe mine's stuck on lowest throttle with nouveau :)03:31
Sarvattit probably doesnt lower the voltage at the different speeds on the older cards is my guess03:32
RAOFThat may well be it.03:32
bjsniderSarvatt, what card do you have?03:32
Sarvatt8400M GS03:32
bjsniderhow long have you had that laptop?03:33
Sarvatt2 years or so03:33
bjsnideryou've far exceeded the lifespan for a bumpgate chip as far as i'm concerned03:34
Sarvattyeah I got this one as a replacement for an older model that went through 3 replacements due to the crappy BGA mounted nvidia chips03:35
Sarvatti havent even really used it in 1.5 years since i got a netbook, its mostly run headless so that might be why :D03:36
bjsnideri figure the card in my rig has only lasted 2 years because it always remains at the same temp, because i never turn it off03:36
bjsniderah, i c03:36
afvhmm, this was not good :p03:49
afvand my apt/cache folder just disappeared :s03:50
afvXorg log: http://pastebin.com/d1e65e6d603:51
RAOFafv: Hows about dmesg; the problem is that nouveau's kernel module hasn't loaded, and the DDX won't work without it.03:53
RAOF(In fact, the DDX is about to have the non-KMS codepath removed, too).03:53
afvi didn't save dmesg :\03:56
afvbut i have something like "kernel: [   34.250444] Xorg[4301]: segfault at 18 ip 00000018 sp bffefc5c error 4 in Xorg[8048000+19f000]" at syslog03:56
RAOFYeah.  Everything will break if you don't have the kernel module loaded.03:56
afvwell, i gotta go now03:56
afvwill be back later03:57
afvthanks for all the help =)03:57
afvkeep up the good work03:57
afvc ya03:57
RAOFafv: FWIW I've just got compiz a-runnin' again on my 7600go04:05
afvnice :)04:07
RAOF...and GPU lockup again.04:31
bjsniderit's not a lockup it's an unscheduled lack of complete functionality04:32
RAOFNo, it's an actual lockup.04:38
Sarvattstill no libxcb update.. did it get held up because of the new libxcb-dri2 package maybe?05:07
wgrantCan I force radeon/fglrx to POST my card when X starts?05:28
tjaaltonbryyce: I wanted to be sure that the libdri/libglx stuff is done before uploading it06:58
tjaaltonI didn't notice that change until tseliot was gone06:59
bryycetjaalton, okay07:12
tjaaltonand looks like mesa needs to move libGL to somewhere else than /usr/lib for the alternatives to work...07:13
tjaaltonit's getty uglier every day :/07:13
tjaaltonI don't like how everything is changed to cater for nvidia07:13
bryyceheh, yeah this is the kinda stuff pitti was worried would happen07:14
tjaaltonwe'd be using this forever, or as long as nvidia ships blobs07:14
tjaaltonRAOF: I'm pretty sure RHEL6 will have nouveau by default07:15
tjaaltonbut they have the manpower to maintain it07:15
tjaaltonit would be great if mark did what he said here http://www.markshuttleworth.com/archives/9507:16
tjaaltonas pointed out by airlied on dri-devel@ during the nouveau discussion..07:17
tjaaltonoh well, enough ranting, more waking up ;)07:19
tjaaltonSarvatt: we wouldn't have to bump the api twice, in fact not at all since the inputclass bump was only for wacom IIRC (and that can be patched in the driver)07:26
tjaaltonneed to check07:26
tjaaltonthe other abi bump was due to "Add type name argument to CreateNewResourceType"07:30
bryycetjaalton, maybe you should email mark to remind him of that ;-)07:31
tjaaltonbryyce: really? :)07:31
tjaaltonit's too late for lucid anyway I think07:31
bryyceactually, half the problem is that it's hard to find X.org engineers wanting to come work for us07:32
bryycebut as a general rule canonical tends to focus resources more to integration and polish than to raw development, especially at the driver level07:34
tjaaltonbut I think it's partly due to the devel community thinking C wouldn't let them continue upstream work, but mostly just distro stuff07:34
tjaaltonhehe, spot on :)07:34
bryycewell and if you think about it, redhat is kind of unique in the amount of upstream development they do07:35
bryycebut that is a business strategy they use, that lets them sell themselves to customers07:36
Sarvattoh boy, didnt notice the mesa problem with the PPA nvidia there07:37
tjaaltonthe way I see it is that after some point the organisation needs to contribute more upstream work to be a "valuable player" or something such07:38
tjaaltonand that's what "the others" think07:39
SarvattLIBGL_ALWAYS_INDIRECT=1 glxgears/compiz/whatever works but Error: couldn't get an RGB, Double-buffered visual without07:39
tjaaltonyou didn't notice there was no compiz? :)07:40
Sarvattdont use it, nope07:40
bryycetjaalton, it doesn't matter.  They still complain anyway.  Look at how heavily I worked with upstream on QA for -intel this past year, pushed bug reports up, quirks, lots of testing, documentation, and on and on07:41
tjaaltonbryyce: but you're just one man :)07:42
bryycetjaalton, so?  upstream (well, specifically RedHat) still does not recognize any of that as having contributed any value upstream07:43
tjaaltonbryyce: my point was that there's only so much one man can do, and that can get lost in the noise07:47
tjaaltonI know it's not fair to compare to RH07:47
bryycetjaalton, true, it still is quite demotivating to me personally to hear all this.  Makes me want to go work on launchpad or something instead.  ;-)07:47
bryyceheck, we actually have 3 paid people full time on X, and it's still not noticed07:48
tjaaltonyou have?07:48
bryycebut redhat's been at this game for a lot longer, I think give canonical time and we'll see07:48
bryycetjaalton, well, we have one kernel guy full time devoted to X (sconklin this release, andy last time), and for lucid alberto is on X 4 out of 5 days07:50
tjaaltonbryyce: ok, didn't know that07:51
tjaaltonso if I haven't noticed that, what does it tell ;)07:51
* tjaalton runs07:51
bryyceyeah exactly07:51
bryycewell, honestly with us all buried under the deluge of incoming bug reports it's hard to really put time into anything beyond fighting fires07:52
bryycewhen I'm feeling really cynical I think to myself that if we had more people who could do work upstream, I'd have them sit on the hands of upstream developers so they quit changing all this shit ;-)07:53
bryyceof course then I'm sure our own Dx team would come up with some brilliant shit that should be changed upstream...07:54
tjaaltonhehe :)07:56
bryyceand we'd still get ripped because we'd be working on foo, when upstream would rather have us doing bar07:59
tjaaltonwell, with X there should be less chance for that. apps, sure08:00
bryycetjaalton, heh now you've got *me* ranting ;-)08:00
tjaaltonbryyce: that was to be expected ;)08:01
tjaaltonaanyway, back to reality. I'll test the inputclass/x.c.d patches skipping the abi bump08:02
tjaaltonhmm, need to go shoveling. we got maybe 50cm snow already08:07
tjaaltonand next week I'll be joining the rest of the family in lapland, where there is -35 right now :P08:19
Sarvattgot wacom working!08:19
tjaaltonSarvatt: ya08:20
Sarvatttook 2 udev rules08:21
tjaaltonshow 'em08:21
Sarvattneeded one to make the input/wacom symlink and another for xserver handling, one sec08:21
tjaaltonyeah the package always had the first one08:22
Sarvatti'm not using the old packaging, didnt have any luck with the old xserver-xorg-input-wacom.rules file08:23
tjaaltondo all the buttons work? or xsetwacom?08:25
Sarvattgraphires working right, i'm digging out my intuos 3 now to test extra buttons08:26
Sarvatttrying to find where i built this wacom, didnt install xsetwacom with the package but it built08:28
Sarvattyeah all looks to be working fine08:33
Sarvattpicked up the extra pad of buttons on the intuos and such and they work08:36
tjaaltoncould you put the source somewhere, I'll try it on my aiptek/waltop08:37
Sarvattsure one sec08:38
Sarvattthis wont work for serial tablets though since they're tty, i saw thjaeger posting patches to try to get it working on the linuxwacom-devel list08:38
tjaaltonmine is usb08:39
tjaaltonI suspect it'll fail miserably, but we'll see08:40
tjaaltonintuos4 was out of stock :/08:40
tjaaltonand still is08:40
tjaaltonoh man.. intuos4 L up for an auction08:42
Sarvattthe packaging is screwy, i just took thjaeger's latest and threw it in a new git checkout, it needs to install xsetwacom and not install the hal stuff on top of needing udev rules08:42
tjaaltonA4 wide size08:42
Sarvattoh nice08:43
tjaaltononly a few months old, 360e :P08:43
Sarvattthis intuos3 4x6 cost way too much08:43
tjaaltonthey are pricey08:46
superm1why did tseliot want libvdpau in main?08:48
superm1does something in main support building against it?08:48
Sarvattdont think that udev rule is going to work since the vendor doesnt match, looks like the hal fdi file was what let waltop work08:49
tseliotsuperm1: isn't that required by nvidia or is it just for development?08:49
tjaaltonSarvatt: I'll fix that part08:49
superm1oh you're here08:49
Sarvattffmpeg or mplayer?08:49
superm1tseliot, it's only needed if your application supports vdpau acceleration08:49
Sarvattor gstreamer?08:49
superm1which is mostly ffmpeg apps like mplayer and mythtv right now08:49
superm1i dont think gstreamer has support yet08:49
superm1at least i havent heard of it if it does08:50
tseliotsuperm1: and shouldn't nvidia recommend that package?08:50
superm1tseliot, no it shouldnt08:50
superm1the apps that use it should08:50
superm1had this discussion with some people in debian and with bjsnider 08:50
superm1if anything there could maybe be an enhances 08:51
tseliotok, so basic support for vdpau lives in the driver but if you want to use it you'll have to install an additional package08:51
superm1well not entirely accurate08:51
superm1the basic support to open an implementation lives in the libvdpau package. the nvidia implementation lives in the nvidia package08:51
superm1the user wont have to install the second package either08:52
superm1it will be a shlibdeps for any package built against libvdpau-dev08:52
RAOFOh, there's some implementation in libvdpau?  I thought it was basically “make it easy to dynamically load the appropriate library when it's available".08:52
superm1the implementation itself doesnt live in libvdpau, no.  08:53
superm1support to "open an implementation"08:53
superm1so dynamically loading the library is right08:53
tseliotsuperm1: also, any ideas as to why libGL.so.1 provided by nvidia is not loaded before libGL.so.1 provided by mesa? http://pastebin.ubuntu.com/353366/08:54
Sarvattthe hal fdi was adding       <match key="info.product" contains_outof="Wacom;WALTOP;WACOM">        <merge key="input.x11_driver" type="string">wacom</merge>, and the udev rules just matched wacom product id's so i dont know that its going to work unless you add your tablets product id to the udev rule?08:55
tseliotsuperm1: the path to the former is in /etc/ld.so.conf.d08:55
tjaaltonSarvatt: it doesn't use the kernel module08:56
superm1tseliot, hm.  not positive..08:56
superm1tseliot, where's the path to the mesa one referenced?08:56
superm1also ld.so.conf.d?08:56
tseliotsuperm1: I think our last resort would be to use preload08:56
superm1tseliot, ugh that's not a good solution to rely on08:57
superm1because every app would have to do that08:57
tseliotsuperm1: no, there's no need to specify /usr/lib as it's automatically picked up08:57
tjaalton /lib and /usr/lib are trusted paths, used by default08:57
tjaaltonSarvatt: meaning that the funcionality is limited, but at least pressure sensitivity worked at some point08:58
tseliottjaalton: right08:59
superm1tseliot, how does mandriva get around this?08:59
superm1i would think the priorities would work out identically08:59
tseliotI'm talking to them right now08:59
tseliotyes, they should and the same system seems to work well for them09:00
superm1are they maybe also using LD_LIBRARY_PATH too?09:00
tseliotthat would explain it09:01
tseliotit looks like they don't09:02
Sarvattdoes the kernel recognize it as a tablet? imagine that 67-xorg-wacom.rules would pick it up if so since it loads wacom for all ID_INPUT_TABLET09:02
tjaaltonSarvatt: haven't tried yet ;)09:04
tjaaltonSarvatt: yes it does09:11
tjaaltonid_input adds ID_INPUT_TABLET=109:12
Sarvatti cant load wacom without that extra udev rule making the symlink, but maybe thats just because i'm using the wacom module.. the old udev rule only touched things with a wacom product id from what i see09:15
Sarvattand it just matched some extra things that work with it like waltop in the fdi09:16
tjaaltonSarvatt: heh, I need a patch from the wacom list to make it work with inputclass09:43
tjaaltonbut lunch first09:46
Sarvatttseliot: if i strace ldconfig it messes with the /usr/lib/nvidia-current stuff before the /usr/lib stuff..09:49
tjaaltonsweet, InputClass & xorg.conf.d works(tm)10:22
tjaaltonthough it also tries to load drivers for /dev/input/mouse*, which is confusing10:25
tjaaltonand wacom loaded too, but doesn't do anything :)10:25
tjaaltoninput-events doesn't show any events either10:30
jcristauwacom_drv might grab the device10:31
jcristauso make sure to test from a vt10:31
tjaaltonit works for the keyboard though, but I will10:31
tjaaltonwhoa, it _does_ work from a vt10:32
tjaaltonhmm and I think whot is off by now10:32
jcristauevdev doesn't grab so the keyboard is fine, yes10:33
jcristaubut synaptics and wacom...10:33
tjaaltonhmm ok10:33
jcristaubryyce: i'm not sure counting tseliot as "working on X" is quite accurate, from what i can see he's working on nvidia and fglrx.  which isn't quite the same thing.10:50
tseliotjcristau: ???10:50
tseliotjcristau: this is only my 1st task10:51
tseliotas soon as I'm done with the alternatives system I can spend time on open drivers and X in general10:52
jcristauokay then.  we'll see.10:53
tjaaltonnow you woke up the bear ;)10:53
tseliotjcristau: were you replying to something that bryyce said? I think I'm missing context here10:54
JamieBennettI'm trying to determine if 3D acceleration is available in X so we can either install a 2D or 3D netbook-launcher interface on ARM devices. What's the best way to determine this?10:54
tseliotglxinfo | grep direct10:55
tseliot(in theory)10:55
JamieBennettwhy in theory?10:57
tseliotit should work10:58
tjaaltontseliot: yeah I was chatting (ranting) with bryyce about the priorities and upstream contributions :)10:58
JamieBennettOK, I'll do some experimenting, thanks10:58
tjaaltongot upset about the nouveau situation, and how it could be better10:58
tjaaltontseliot: btw, is the libglx/libdri change in xserver good to go?10:59
tseliottjaalton: oh, I see. As soon as I finish this I'll be able to work on the input.d class as promised to upstream. I would also like to help with open (graphics) drivers. We'll see10:59
tjaaltonand great to hear11:00
tseliottjaalton: yes, those are fine. The nvidia part is required now11:01
jcristau(glxinfo|grep direct won't tell you whether stuff is accelerated)11:06
JamieBennettjcristau: any other thoughts if thats not it?11:08
jcristaulook for the renderer string11:08
tseliotright, only if you have direct rendering11:08
JamieBennettso glxinfo | grep 'renderer string'11:09
jcristautseliot: which you always have.11:09
tseliotjcristau: not always11:09
jcristauunless you don't have it on purpose, but then you know.11:10
tseliotor your system is partially broken11:10
JamieBennettjcristau, tseliot: Is there anyway of determining this without glxinfo? We don't have that in our live images.11:24
tseliotyou can install mesa-utils11:24
tseliotwhich contains glxinfo11:24
tseliottjaalton: I think I'll just move libGL.so* to /usr/lib/standard-x11 (as I did for libglx.so and libdri.so) and use alternatives to point to other that or nvidia or whatever we select11:59
tseliotthis will make sure that, as it already happens in some linux games (as the Mandriva developer told me), if they dlopen libGL.so.1 directly things will still work12:00
tjaaltontseliot: hrm, so the outcome is that in order to be able to select the GL implementation, we had to change three non-blob packages. and irreversibly, most likely12:03
tseliottjaalton: x, mesa, libxvmc (even though the 3rd one could be avoided)12:04
tseliotbut yes12:04
tjaaltonI guess there's no going back, so commit & upload what you need12:14
tseliotright, I'm getting mesa from git as we speak12:16
tseliottjaalton, jcristau: do we override configs/linux (in mesa) in the debian/rules?14:04
tjaaltontseliot: they are not used since autoconfig14:04
tseliottjaalton: I've found out what sets the ".note.ABI-tag" in mesa that breaks things for us14:11
tseliotgenerated by src/mesa/glapi/gl_x86_asm.py14:12
tseliotand the other x86_64 script14:12
tseliotthe ABI-tag is set if we enable tls14:12
tseliot#if defined(GLX_USE_TLS) && defined(__linux__)14:13
tjaaltonwhy doesn't mandriva enable it? the only reason why fedora doesn't is selinux14:14
tjaaltonand that'll change sooner or later14:14
tseliotlet's what they say14:14
jcristauwhat does that supposedly "break"?14:15
tseliotjcristau: well it doesn't really break anything. It simply makes ldconfig believe that the libGL.so.1 in mesa is a completely different library from what other vendors, say nvidia, provide14:17
tseliotlibGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.114:17
tseliotlibGL.so.1 (libc6) => /usr/lib/nvidia-current/libGL.so.114:17
tseliotthe first one is from mesa14:18
tseliottjaalton: I've come up with a solution that doesn't suck :-)15:27
tseliottjaalton: i.e. we simply install libGL.so* to /usr/lib/mesa (or whatever) and the file in ld.so.conf.d/ (that we already use) will make ldconfig look for libGL.so* look in the right place15:29
tseliot(well, it doesn't suck too much)15:29
tjaaltontseliot: ok15:42
tseliottjaalton: so the diff in mesa will be very small15:42
tjaaltonthat's good15:42
apwbryyce, hey are we good for alpha-2 to have ATI radeon KMS enabled?15:56
tjaalton it wasn't already?15:57
tjaaltonapparently not, I thought it was enabled after alpha1 :)16:00
apwtjaalton, it was an is enabled since just after alpha-1, just making sure 'you' are ok with it remaining so for an annouced released16:02
tjaaltonapw: ah, ok16:02
Sarvattpretty sure its almost guaranteed you're not going to have 3d acceleration on any arm platform, we disable egl and stuff in mesa16:16
BUGabundo_workbug 50414916:33
ubottuLaunchpad bug 504149 in xorg "[lucid] after update keyboard and mouse do not work in X" [Low,Won't fix] https://launchpad.net/bugs/50414916:34
BUGabundo_workif anyone cares to take a look, and help me save my (and probably many other Lucid user) systems16:34
BUGabundo_worktseliot: ^^^^^^^16:34
tjaaltonyour logs indicate that hal is working normally, so what's wrong?16:36
BUGabundo_worktjaalton: no mouse or keyboard in my system16:37
BUGabundo_workafter upgrades from two days ago16:37
BUGabundo_workand yesterday reboot16:37
BUGabundo_worktouchpad works, actually16:37
tjaaltonok, probably due to the faster boot work16:37
BUGabundo_workif i stop GDM i can use keyb in TTY16:38
tjaaltonso, pretty please, dist-upgrade and be done with it16:38
BUGabundo_workit forces the removal of nvidia driver and kernel16:38
tjaaltonsurely you can live without nvidia for a few days?16:38
tjaaltonkernel? no it doesn't16:38
BUGabundo_workbeen like that for 1 month16:38
tjaaltonyeah, and you updated anyway?16:38
BUGabundo_worki never dist-upgrade when _important_ packages are touched16:39
BUGabundo_workaptitude safe-upgrade only16:39
tjaaltonso expect breakage16:39
BUGabundo_worki do16:39
BUGabundo_workbut not being locked out of my own system16:39
tjaaltondist-upgrade ftw16:40
BUGabundo_worki wouldnt been running +1 for 3 years not expecting breakage16:40
BUGabundo_workvery funny16:40
tjaaltonyes it is16:40
BUGabundo_workhow about packaging proper matching X with close source drivers ?16:40
tjaaltonI don't understand what you are asking on that bug16:40
BUGabundo_workthat would be funny too16:40
tjaaltonyes, I'm laughing16:40
BUGabundo_workoh i bet16:41
BUGabundo_worki'm laughting too... for not being and ATI user16:41
tjaaltonbug 49416616:41
BUGabundo_workohh wait... i'm too.. debian unstalbe at work16:41
ubottuLaunchpad bug 494166 in nvidia-graphics-drivers-96 "[lucid] nvidia-glx can't work with new xorg 7.5" [Medium,In progress] https://launchpad.net/bugs/49416616:41
* BUGabundo_work subs16:41
BUGabundo_worktjaalton: can u assure me the return of my input devices after dist upgrade, and provide a proper downgrade route, in case that fails ?16:43
tjaaltonthe downgrade path is to install karmic16:43
tjaaltonif you desperately need the nvidia16:43
BUGabundo_workdo that to all your testers16:43
BUGabundo_workand be left with a borked final system16:43
BUGabundo_workno, i dont want nvidia that bad16:44
BUGabundo_worki want my mouse and keyb.... *that bad*16:44
tjaaltonyes, I bet it works16:44
BUGabundo_work100$ and u are on16:44
BUGabundo_worki need to pay my new WD16:44
BUGabundo_worku can start helping16:44
tjaaltonsince this is the first bug about this..16:44
tjaaltonand I need a wacom :)16:44
BUGabundo_workwell, second16:44
BUGabundo_worki subbed to that bug16:44
tjaaltonjust because you didn't dist-upgrade16:45
BUGabundo_workwell... dont break X and ask for the removel of N packages including a kernel image16:46
tjaaltonwhat kernel image??16:46
tjaaltonthere's a reason for the video abi conflicts you know16:46
BUGabundo_workcant say out of my head16:46
tjaaltonsince your nvidia wouldn't work with 1.716:46
BUGabundo_worki know16:46
BUGabundo_worknew X16:46
BUGabundo_worki know and i understand16:46
tjaaltonthen why do you complain?16:47
BUGabundo_workhence the reason i didnt dist-upgrade16:47
BUGabundo_worktjaalton: cause it broke my input methods16:47
tjaaltonno, that's the plumbing16:47
tjaaltonand we went to udev input handling before alpha1, so hal was never tested nor meant to be used16:48
BUGabundo_worki know16:49
BUGabundo_workit wasnt there!!16:49
jcristauactually it's expected to break, the fdi enabling X i-h was removed from hal16:49
BUGabundo_workthat's the secondary bug16:49
BUGabundo_workseems it was pulled again into my system16:49
bjsniderhal was?16:51
tjaaltonjcristau: oh right, so no way hal can work16:51
tjaaltonhmm no, running the old version it should16:51
tjaaltonjcristau: damn, didn't read it well enough :)16:52
jcristautjaalton: might be a good idea to have the new hal Break old xserver-xorg-core just to make sure?16:52
tjaaltonjcristau: yes, why not16:52
tjaaltonjcristau: pushed 1.7.416:54
tjaaltonbjsnider: hal is needed on some laptops for gnome-power-manager. it will be modified to run only when needed16:55
bjsnideroh, cool16:55
bjsniderthat kind of sucks though, doesn't it? it has to be installed by everybody ony for that one small use-case16:56
bjsnidergnome-power-manager needs to be slapped around a bit16:57
tjaaltonBUGabundo_work: so, the way to make hal work again is to go back to the version on karmic16:57
tjaaltonbjsnider: yeah I think it'll get fixed sooner or later, but not necessarily for lucid16:57
tjaaltonheh, "All the X drivers need to support XBACKLIGHT before we can turn it off completely"16:58
jcristauwhy the shouting?16:58
BUGabundo_workso either downgrade hal, or distupgrade, lose nvidia, what get my self into what hell, until nvidia release 1.7 compatible driver17:03
BUGabundo_workok... at least i have a choise17:04
bjsniderdoes the blob not work with the new x server?17:04
bjsnidereverybody who's emailed me about it says it does17:05
tjaaltonbjsnider: which version?17:07
tjaaltonBUGabundo_work: there is a compatible one available, it's just not packaged yet17:07
tjaaltonbut soon17:07
tjaalton190 is on tseliot's ppa17:07
bjsnideri packaged all 3 for lucid at one point until yesterday and everybody reported to me that they worked17:08
tjaaltonoh, the old packaging17:08
bjsniderright, the old packaging17:08
tjaaltonanyway, gotta go17:08
kalossmi tarjtea grafica17:09
kalossno acepta los afectos visuales17:09
jcristauin english please17:10
bjsnideri think he's saying he can't enable visual effects17:10
tseliotkaloss: puede depender de varios motivos pero tienes que hablar inglés17:10
jcristaui got that much :)17:10
kalossmy efeccts visual17:10
kalossmy moptherboard pc chips 955 integrated17:11
tseliotkaloss: did you file about report about it?17:12
kalossseen here----> http://paste.ubuntu.com/353541/17:15
tseliotI meant to say, did you file a bug report about it?17:21
tseliotkaloss: no, unfortunately you won't get 3D effects with a VIA card17:22
jcristauugh via17:22
jcristautough luck.17:22
* tseliot nods17:22
jcristaualmost as bad as poulsbo ;)17:23
tseliotnow you're reading my mind...17:23
bjsnideri thought via had opened everything up and hired a couple of the openchrome guys?17:26
tseliotno, 3D is still proprietary17:26
jcristaui very much doubt "everything"17:26
bjsnideraren't they developing a gallium driver?17:27
tseliothad they opened everything, things would have been in much better shape now17:27
tseliotbut even with gallium you can keep it closed17:28
bjsniderwell, they're definitely better than they used to be17:28
bjsniderwhich isn't saying much, because there was no place to go but up for them17:29
tseliottjaalton: I'm rebuilding mesa locally now. If it works, I'll push my changes for X and Mesa to git and we can start uploading things17:33
tselioti.e. patch for X: http://pastebin.ubuntu.com/353554/17:38
tseliotpatch for mesa: http://pastebin.ubuntu.com/353556/17:38
tseliottjaalton: ok, pushed to git17:59
tseliotwhy shall I use debuild -I".git" -S -sa -v$previousUbuntuVersion ?18:01
tseliotthe -v part18:01
jcristausee dpkg-genchanges(1)18:05
tseliotjcristau: aah, ok, it makes sense now18:06
tseliotbut still -sa shouldn't be required unless is a new upstream release18:10
tseliot-S should be enough18:11
bjsnideror -S -sd18:12
bjsnideri thought18:12
tseliot-sd    Forces the exclusion of the original source and includes only the diff.18:13
tseliot-S     Specifies that only the source should be uploaded (no binary packages will be included).18:13
bjsniderright, so if i'm just changing the build scripts that's what i do18:15
tselioteither of them should be ok in this case18:16
bjsniderand the ppa build system and my rig both have the same orig tarball, so that's why it wor,s18:16
* tseliot -> dinner (brb)18:19
Sarvattjcristau: dunno if you saw but the remove render reclock commit went to stable, definitely still needs powersave=0 on top of that here though, i'm still getting flickering after resume without it. still dont understand why powersave=0 doesnt fix it without that commit as well though18:44
jcristauSarvatt: okay.  i think i'll get the debian kernel people to set powersave to 0 by default and call it quits... thanks for the heads up18:45
Sarvattyou install a /etc/modprobe.d/intel-kms.conf with the driver, why not just throw it in there?18:46
Sarvatterr i915-kms.conf18:47
jcristaubecause it's safe to do in the kernel18:47
jcristauand if it's going to be temporary it's better done there18:47
Sarvatttrue, it breaks <.32 adding it in the modprobe.d/i915-kms.conf18:48
Sarvatti915 doesnt load because of the invalid parameter on 2.6.31 when i add it in there18:48
jcristauassuming the intel people get their stuff working in .33 i'd rather not have to clean things up when we bump the kernel18:48
Sarvatti'm glad linus seems to not care about feature freezes for intel and pulls drm-intel-next whenever its ready :D18:53
Sarvattok i guess its time to drop xserver from xorg-edgers, going to have to put a big warning for people to revert those packages manually at the top and hope people read it :D18:53
Sarvattif I delete it ppa-purge wont revert it though, ugh18:55
Sarvatttjaalton: seems like we could hack together a wacom package that only works for usb devices now doesn't it? I wish thjaeger came on irc, looks like he's working on extending it to work for serial devices using tty instead of just input19:01
Sarvatthe's sent me patches that do work for the old 0.8.x wacom packages under input abi 7 but that only works with hal19:02
Sarvatti'm an idiot when it comes to udev so I can't figure out why the old udev (non-xorg one) doesn't work but my one that just creates the input/wacom symlink does19:04
Sarvattold udev rules file I mean19:04
bryyceapw, yep +1 from me19:09
=== vish is now known as mac_v
=== mac_v is now known as vish
tseliotbryyce, tjaalton: I have uploaded my changes to X and Mesa. I'll upload libxvmc now19:11
thopiekar-t91is there a site on the net that provides new poulsbo drivers19:15
thopiekar-t91I copied fails builds from other repos to my and made them work on my ppa:thopiekar/poulsbo19:17
tseliotthopiekar-t91: we don't support poulsbo any more19:18
thopiekar-t91is there a alternative..19:18
tseliotbut you will find some unofficial repositories on ubuntuforums.org19:18
thopiekar-t91can you at least help me to get it work..19:18
tseliotuse them at your own risk though19:18
thopiekar-t91tseliot: the howtos there are using ubuntu mobiles jaunty ppa but I want to push them to karmic19:19
thopiekar-t91jcristau: I think I'm using atm vesa .. it's really eating my battery's energy :/19:20
tseliotthopiekar-t91: http://swiss.ubuntuforums.org/showthread.php?t=125340619:20
tseliotfeel free to push whatever you like in your ppa19:20
thopiekar-t91yes but these packages doesn't work.. ok I will work on it, thank you anyway..19:22
bryycetseliot, with those changes, what's next on the todo for the alternatives stuff?19:23
tseliotbryyce: the 3 nvidia flavours (which I'm ready to upload)19:24
tseliotthen I would like to upload screen-resolution-extra, nvidia-common, nvidia-settings and (when pitti is online) the new jockey19:24
* bryyce nods19:25
tseliotbryyce: screen-resolution-extra is used by nvidia-settings to use policykit19:25
tselioti.e. no more sudo with nvidia-settings19:25
tseliotbryyce: I think I'll make some additional changes to the alternatives system but this will be after alpha 219:26
Sarvattthis whole setup breaks being able to use drivers directly from nvidia doesn't it?19:27
tseliotSarvatt: if nvidia-common is installed, the nvidia-installer will stop19:27
bryyceSarvatt, IIUI you would need to uninstall the ubuntu driver, then you could install from upstream19:27
Sarvattah I purge nvidia* when I use the nvidia drivers19:27
tseliotbut yes, the nvidia-installer, even if successful  won't work because of the ld.so.conf.d stuff19:28
Sarvattjust thought the shuffling of libs might screw it up somehow19:28
tseliotand I'll fix this19:28
tseliotI was talking to the Mandriva guys about it today19:28
tseliotwe can cooperate on this19:29
tseliot(as we use the same system)19:29
Sarvattalot of people are using the upstream driver because the distro ones dont work right now (me included) so it might warrant a release note for alpha 2 on how it that doesn't work at the moment19:31
Sarvattis what I was thinking19:31
tseliotSarvatt: it's a good idea19:31
bjsnideri think that the 195 driver should be used instead of the 190 for lucid19:32
tseliotbjsnider: sure, as soon as it's released as stable19:32
Sarvatt195 will probably be the stable release any time now I'd bet19:32
Sarvattsuper easy to update with all this work now at least :D19:32
* tseliot nods19:32
bjsnidertseliot, yes but lucid isn't stable so why do you have to package a stable nvidia driver?19:32
bjsniderSarvatt, not super easy. the 195 contains 6 new files that have to be packaged19:33
tseliotbjsnider: what if nvidia doesn't release it as stable in time for Lucid's release?19:33
bjsniderthey will. no question19:33
tseliotin general, this is my approach, especially with things that I can't fix19:34
Sarvattactually, 190.53 isn't even a stable release yet is it?19:34
tseliotnamely proprietary stuff19:34
tseliotyes, it was promoted to stable19:34
bjsnidertseliot, i just figure, what with those new files, why not put them into the build scripts now while you're working on them as opposed to having to jump back into them knee-deep in a month?19:34
Sarvattah indeed it is19:35
bjsniderplus kde users should be using the 195 since it accelerates xrender for the first time19:35
tseliotbjsnider: I can put 195 in a PPA and experiment there19:35
bjsniderthere are two shared libs that will have to be execstacked and linked19:36
bjsniderand a file that goes in /etc19:36
bjsnider3 opencl headers19:37
tseliotnow we have this deadline that is alpha 2 and I have to make sure that things work in time for alpha 2, then I can think of the rest19:37
tseliotah, good to know19:37
bjsnideri just figured it would be easier on you to do this work while the build scripts are all in your mind as opposed to leaving it for a month and then having to pick it all up again19:38
Sarvattare the headers in a standard place? picked up by the current install globs?19:38
bjsniderthey are in /usr/lib/CL19:38
bjsnideri don't think the installer would pick them up19:38
bjsnideri think the installer would pick up /usr/lib/libnvidia-compiler.so.195.xx19:39
bjsniderbut it would have to be linked in the .links file19:39
bjsniderthe windows driver is already at 195, and the linux team likes to stay current with that, so they'll be switching as soon as they get the major bugs out of the 19519:41
Sarvattgreat, nvidia-current-cl nvidia-current-cl-dev packages then..? is there any generic libcl it hooks into?19:42
tseliotwait, what?19:42
bjsnideri thought we didn't want to split anything off19:42
tseliotone will end up in nvidia-current, the rest in nvidia-current-dev I guess19:43
bjsniderthe two libs would be in nvidia-current, the 3 headers in the dev package19:43
bryyceSarvatt, are we considering that libdrm execbuf bug solved with latest mesa/libdrm?  I see the bug report is still open upstream19:43
bjsniderand then there's an /etc file19:44
tseliotbjsnider: what's in /etc ?19:44
Sarvattbryyce: I still have the problem with an updated intel ddx but not with 2.9.119:44
Sarvattbut no problem with libdrm/mesa updates without updating the ddx19:44
bryyceSarvatt, weird okay, so as long as we don't upgrade -intel we can go ahead with upgrading libdrm/mesa?19:45
sorenI've been messing around with my drivers lately (part manually, part from tseliot's restricted-blah-blah ppa, and part ubuntu repositories), and finally the nv driver is working for me, but DRI does not seem to be working. Is this expected, or did I mess something up along the way? (Using the "nv" driver, by the way)19:46
bjsnidertseliot, /etc/OpenCL/vendors/nvidia.icd -- it contains this: libcuda.so19:46
bryycetjaalton, ^ is uploading the new libdrm/mesa on your todo list?  If not, should I give it a go?  Would be nice to have done for a219:46
SarvattI'm really confident enough to say yes to that after 4 days testing, libdrm 2.4.16 alone had a crashing problem that must have been been fixed in 2.4.17 (there were a few intel bug fixes)19:46
tseliotsoren: what did you take from my PPA?19:47
sorentseliot: Let's put it this way: It's in my sources.list, and apt says I'm all up-to-date.19:47
tseliotbjsnider: hmm... I'll ask nvidia about it19:47
bjsnidersoren, glx isn't working?19:47
bjsnidergood idea19:48
sorenbjsnider: Well... 5 minutes ago, glxinfo just gave some error (sorry, I forget the exact error), which was caused by libdri.so was pointing to the nvidia-current one.19:48
tseliotsoren: /var/log/Xorg.0.log ? and the output of update-alternatives --display gl_conf please19:48
sorenbjsnider: Now, I do get some useful output, but "direct rendering: No (LIBGL_ALWAYS_INDIRECT set)19:49
sorentseliot: gl_conf? What's that?19:49
Sarvattthe bug was so severe before i never had over 24 hours uptime with the newer ddx, 4 days *trying* to crash it by repeatedly loading a folder with hundreds of videos and letting it make thumbnails and deleting those thumbnails and repeating when I couldnt last 2 rounds of that before seems like its fine to me19:49
tseliotsoren: the master link19:49
sorenAh, I see.19:49
bryyceSarvatt, ok good to hear19:49
bryyceSarvatt, happen to know if updating libdrm/mesa is on tjaalton's todo list for a2?19:50
sorentseliot: Hahah, that's pointing at /usr/lib/nvidia-current/ld.so.conf19:50
tseliotsoren: type: sudo update-alternatives --set gl_conf /usr/lib/standard-x11/ld.so.conf and then do an ldconfig19:50
sorentseliot: As I said: "part manual fiddling" :)19:50
tseliotalways with sudo19:50
sorentseliot: Sure, sure.19:50
tseliotsoren: when all is in place jockey will deal with that19:50
SarvattI have no idea :( seems like he wanted to push it ASAP though and the libdrm is blocking alot of other possible updates19:51
Sarvattbut I think he wanted to adjust libdrm so it replaces headers again which intel 2.10 needs to build19:51
sorentseliot: That did not do the trick. I'll pastebin my xorg.0.log.19:52
bryyceah right19:52
jcristausoren: if you still have LIBGL_ALWAYS_INDIRECT set, unset it?19:52
sorenjcristau: Um... I didn't set anything. Is it an environment variable?19:53
bryyceSarvatt, ok I'll touch base with him when he's around but won't pick at it myself for now19:53
bjsniderwow, the nvidia driver package for windows is 105 MB19:53
sorenjcristau: Oh, wow. It is an environment variable. Where the heck did that come from?19:53
tseliotsoren: BTW nvidia doesn't provide libdri.so. Even if you select nvidia you will use libdri.so from X1119:54
SarvattJamieBenett: I'm almost positive you arent going to get accelerated GL on any arm platform in ubuntu right now, they all have proprietary graphics accelerators that would need to interface their opengl ES implementations with egl for acceleration as far as I know19:54
sorentseliot: I didn't say all my manual fiddling was sane :)19:54
sorenUm... What would set LIBGL_ALWAYS_INDIRECT ?19:55
jcristausomething that's trying to run compiz?19:55
Sarvattany we dont even build mesa with egl support (not that I know that would work with things)19:55
Sarvatti think mythtv sets it too? could be really mistaken there19:56
jcristaui'm not ruling out any mythtv stupidity19:57
Sarvattarm 3D acceleration on linux is worse than paulsboro, most use powervr too :(19:58
sorenjcristau: Ok, if I unset LIBGL_ALWAYS_INDIRECT, glxinfo says "direct rendering: Yes".19:58
jcristau(not that "direct rendering: Yes" means anything)19:58
jcristau(in terms of gl acceleration, that is)19:58
Sarvatti think if you can get a kernel blob interface up you might be able to get it working with gallium though19:59
sorenjcristau: I'm learning a lot today. How can I tell whether it's software rendering or not?19:59
sorenHahah: OpenGL renderer string: Software Rasterizer19:59
tseliotyes, if glx is broken usually you get only errors from glxinfo19:59
jcristausoren: right, that.19:59
sorenjcristau: So what makes the difference here? What provides the drivers for hardware accelerated glx (is that the right terminology)?20:01
sorenIs that mesa?20:02
bryycesoren, yes, for most of the open source drivers20:03
sorenFascinating :)20:04
bryycewith nv, the developers seem to prefer that users needing gl use -nvidia instead20:05
bryyceso gl support for -nv is fairly behind the times20:06
sorenSo when my memory is trying to convince me that I used to have compiz running with nv, it's lying?20:06
tseliotyou can still use compositing with xrender20:06
tseliotwith nv20:07
tseliotI think I did that with KDE 4 once20:07
hyperairhuh? you can?20:07
tseliotopenGL is much better20:07
sorenOh, well.20:08
tseliotyou can try that with a Kubuntu live image20:08
tseliotnote: I'm not suggesting that you do it ;)20:08
sorenI suppose I'll try to get nvidia working instead.20:09
tseliotsoren: with my PPA + the new xserver and mesa that will soon arrive directly in Lucid, 3D acceleration should work20:10
sorentseliot: update-alternatives --set /usr/lib/nvidia-current/ld.so.conf gl_conf, and then s/nv/nvidia/ in xorg.conf, and I should be golden?20:11
sorentseliot: You mean for nvidia or nv?20:11
tseliotsoren: "update-alternatives --set gl_conf /usr/lib/nvidia-current/ld.so.conf" and yes, I was referring to nvidia :-)20:11
sorentseliot: Uh, right, sure, that's what I meant (the update-alternatives thing). :)20:12
* soren is lying.20:12
sorenI'm actually using --config20:12
tseliotthat's easier20:12
* soren takes this config for a spin20:12
sorentseliot: I get a bunch of "Xlib:  extension "GLX" missing on display ":0.0".", when I run glxinfo now. Xorg.0.log says:20:14
soren[    0.034084] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so20:14
sorendlopen: libGLcore.so.1: cannot open shared object file: No such file or directory20:15
tseliotsoren: did you do ldconfig and do you have my new x and mesa?20:15
sorenEverything is up-to-date, but I forgot ldconfig.20:17
* soren tries20:17
tseliotsoren: are the new mesa and X already in lucid???20:18
sorentseliot: No clue.20:18
sorentseliot: Probably not, since you ask that way.20:18
sorenI was trying to answer your question :)20:19
sorenapt does not want to install any updates, so I've got whatever's freshest in the archive and/or your ppa.20:19
tseliotand the answer seems to be no ;)20:20
* soren waits another three hours then :)20:21
sorentseliot: I'll stop bothering you now. :)20:23
tseliotsoren: no problem, I'll spend the night waiting for the packages to build ;)20:24
tjaaltonbryyce: yes, those are ready20:41
tjaaltonwe can munge the headers after a2, if needed20:41
bryycetjaalton, sounds good20:44
bryycetjaalton, ok do libdrm and mesa need anything before they get uploaded, or are they want to go now?20:45
tjaaltonbryyce: mesa needs to be merged with tseliot's latest change, nothing else20:45
tjaaltonI've got local 'ubuntu-test' branches for both20:46
tjaaltonwonder if they would be useful on git.d.o20:46
tjaaltonfor future work20:46
tseliotanother mesa?20:46
tjaalton7.7 :)20:46
bryyceI'll work on some of the other merges20:49
tjaaltonbryyce: btw, the versions_current lists -amd and -via, both of which are dupes (-geode, -openchrome). those could be filtered out21:00
bryycetjaalton, ok; added to my todo list21:03
tjaaltonbryyce: thanks21:03
knittlhi, i need help with xorg graphics drivers :D21:09
knittleverytime i boot i get an error message about ubuntu running in low graphics mode21:10
knittlexiting to console and starting gdm works fine though21:10
tjaaltonso gdm didn't start the first time21:10
knittli get the message with nvidia drivers from tseliot's ppa, with and without xorg.conf and even with drivers apt-get purged21:11
knittltjaalton: probably21:11
tjaaltonthere's some race condition with the booting process on lucid21:11
tjaaltonit's not a driver bug though21:11
knittlok, so this is a known issue?21:11
tjaaltonat least to me, since I get it all the time21:11
knittlok :)21:11
tjaaltonthe Xorg.0.log was not updated, neither were the gdm logfiles.. so those would suggest that gdm didn't start at all21:12
tjaaltonbut failsafe did21:12
tjaaltonand since upstart doesn't log boot msgs...21:12
knittli just tried to reinstall nvidia-current via jockey, but this time i got an error message21:13
ScislaCSo... haven't asked in a couple weeks and feel it's due. Any chance that we'll get wacom input drivers again in lucid anytime soon? :)21:13
bryyceScislaC, nope21:13
ScislaCbryyce: Oh well... I'll just keep holding off on updating. I just feel like I don't help much with testing when I'm not up to date.21:14
tjaaltonwe might get something for some ppa though21:14
BUGabundofollowing tjaalton advice i dist upgraded21:15
BUGabundonow my lucid is in low grafics mode21:15
tjaaltonbut not in the archive until the debian maintainer is ok with it21:15
BUGabundobut at least mouse and keyb work :\21:15
knittlhi BUGabundo :D21:16
BUGabundohey knittl 21:17
BUGabundoguys any nvidia or nv driver i can use to get proper resulotion ?21:17
knittlBUGabundo: just exit to console and type sudo service gdm start21:17
knittli've had the problem for some time now21:17
tjaaltonBUGabundo: nv doesn't work?21:18
tjaaltonlogfile hen21:18
BUGabundocan i install the one in PPA?21:18
BUGabundoif so, why isnt it in archive?21:18
BUGabundotjaalton: havent tested NV. thats why i'm asking21:18
BUGabundoinstall nvidia vdpau PPA21:30
BUGabundoremoved my xserver-xorg21:30
tjaaltonno you should have -nv installed. if not, install xserver-xorg-video-all21:31
BUGabundolet me se21:32
BUGabundotjaalton: no. -video.all is not here21:32
BUGabundoso how do u purpose i fix the blog?21:32
BUGabundoinstalling X takes nvidia (even from PPA)21:33
tjaaltonuse tseliot's ppa21:35
BUGabundowhy aint that stuff in x-edger PPA or archive yet?21:35
tjaaltonbecause it isn't ready21:36
tjaaltonor wasn't21:36
BUGabundotjaalton: link please?21:37
BUGabundofound it21:37
BUGabundotseliot ppa only has up to karmic21:38
BUGabundono lucid package21:38
tjaaltonlook closed21:38
tjaaltonthere are many ppa's21:38
* BUGabundo blames google21:39
BUGabundox-testing ?21:39
BUGabundosaw it21:40
BUGabundook. package list update . now what? install blob?21:41
tjaaltoni guess21:41
BUGabundotjaalton: which one?21:41
BUGabundoi dont see a 185 / 190 / 195 21:41
tjaaltonyou also need the latest mesa/xserver from the main archive21:41
BUGabundotjaalton: which package name, please?21:42
tjaaltonplease, not too hard to look at the ppa21:42
BUGabundono such thing in my apt db21:43
BUGabundonor is nvidia-current in that ppa21:43
tjaaltonsure is21:43
tjaaltonrest is left as an excercise21:43
BUGabundoi'm sorry21:44
BUGabundoi dont see it21:44
BUGabundonor can i find it with aptitude21:44
BUGabundoi see nvidia-common21:44
bjsnidertjaalton, nvidia-current is not in alberto's ppa. it is call nvidia-graphics-drivers21:46
tjaaltonthen what's this: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements/+files/nvidia-current_190.53-0ubuntu1~proprietaryppa22_amd64.deb21:47
BUGabundono idea21:48
BUGabundoneed a screenshot of https://launchpad.net/~albertomilone/+archive/proprietary-video-improvements/+packages ?21:48
BUGabundocause its not there21:48
tjaaltonwhat about "view package details"?21:48
bjsnidertjaalton, that is created from the nvidia-graphics-drivers package21:48
tjaaltonbjsnider: yes, I thought he was looking for the binary package21:48
tjaaltonapt should find it anyway, after an apt-get update..21:49
BUGabundodid that21:49
BUGabundoprob didnt build for 64bits21:50
tjaaltonboth are there21:50
BUGabundoand trying again21:50
tjaaltonthat won't help apt21:50
BUGabundoi know21:51
BUGabundobut i'm frustrated21:51
BUGabundook 21:52
BUGabundosudo gdm stop21:52
BUGabundonow looking for the driver21:52
tjaaltonwho's alberto-milano?21:54
tjaaltonie. the url is wrong..21:54
BUGabundoone - too many21:55
tjaaltonmilone, not milaon21:55
tjaaltonso, two typos21:55
BUGabundomy eyes are terribly tired21:56
BUGabundoalready put my eye drops21:56
tjaaltoncopypaste ftw21:56
BUGabundolets see if it improbes21:56
BUGabundotjaalton: humm yeah21:56
BUGabundoi still cant see them21:57
tseliottjaalton: lol22:01
BUGabundotseliot: i'm sorry, but its not funny22:02
tseliotBUGabundo: add ppa:albertomilone/proprietary-video-improvements from the Software sources program22:02
BUGabundoi understand you work very hard in providing 22:02
BUGabundothis package the best u can22:02
tseliotI was laughing about my name22:02
tseliotor of what became of my name ;)22:03
BUGabundobut when it subums an user system like this without proper upgrade path, it suck 22:03
BUGabundook 22:03
BUGabundoi see current22:03
BUGabundobut not -graphics22:03
tseliotexperimental releases are not intended to be used by everyone22:04
tjaaltonyou want current22:04
tjaaltonbut your main mirror probably doesn't have the needed mesa/xserver22:04
BUGabundotseliot: i've commited myseft 3 years ago to run at least one box in +122:04
tjaaltontseliot: maybe you should add a Depends on those22:04
tjaaltonfor the nvidia*22:04
BUGabundoso i can test, and provide good feedback22:04
BUGabundoallowing we all to have a good release after 6 monts22:05
tseliottjaalton: aren't transitional packages enough?22:06
tjaaltontseliot: no I mean depends on mesa/xserver22:06
tseliotnote: I haven't uploaded nvidia in Lucid yet22:06
tjaaltonsince 3d doesn't work with the old ones22:06
bjsniderthat is going in today right?22:06
tseliotan archive admin will have to approve nvidia-current though22:07
bjsnideryeah, i'm telling everybody to get rid of the ppa versions that use the old package system22:07
BUGabundoi got -current from PPA22:07
BUGabundodo i need to manually choose a mesa too ?22:08
tseliottjaalton: 3d for nvidia doesn't work with those. 3D with open driver does work22:08
tjaaltonjust make sure you have 7.6.1~rc3-1ubuntu222:08
tjaaltontseliot: umm what?22:08
tjaaltontseliot: you need the new mesa for the libs to be sorted out, right?22:09
BUGabundotjaalton:  i dont! installing22:09
BUGabundolibosmesa6 right?22:09
tjaalton-nv never had 3d, and never will22:09
tjaaltonBUGabundo: no22:09
BUGabundoall others are dgb or dev22:10
tjaaltonwhat you already have installed, just that the version should be that22:10
tseliottjaalton: aah, you mean versioned dependencies on X and mesa22:10
tjaaltonyou don't need to install any new packages22:10
tjaaltontseliot: yes22:10
tjaaltonBUGabundo: then again, that version isn't published yet, so it's not available22:11
BUGabundolets see how this goes22:11
tseliot7.6.1~rc3-1ubuntu2 is what you want22:11
tjaaltonlibdrm uploaded22:11
BUGabundoi have 1280*80022:11
BUGabundothis darn cpu stuck in PERFORMENCE is killing me22:12
BUGabundocompiz doesnt start22:13
BUGabundodo u guys need a trace?22:13
tjaaltonwhat I said, you need the new mesa, but it's not available yet22:13
BUGabundoso tommorrow i just remove the PPA22:13
BUGabundoand upgrade normaly=22:14
tjaaltonprobably so22:14
* tseliot nods22:14
BUGabundoand we are going with nvidia 190?22:14
tseliotBUGabundo: temporarily, yes22:15
BUGabundohey, i can change my GPU power mode now :D22:15
BUGabundodo u guys need a nvidia-bug-report.sh log ?22:15
tjaaltonfor what?22:16
BUGabundoi dunno22:16
BUGabundojust trying to help22:16
BUGabundoproviding what ever my system can pump out22:16
BUGabundoso u guys can check for probs *before* hand22:16
BUGabundobut since u dont, I thanks you all for your hard work22:17
BUGabundoand will now use my laptop to flash my new WDTV 22:17
bjsniderit provides nvidia bug report codes that we don't understand mostly22:17
BUGabundowith a new oficial rom, so i can see my movies22:17
tjaaltonmesa 7.7 uploading.. slowly, killing my irc22:18
sorentseliot: Yay! It works now. Thanks!22:20
tseliottjaalton: I'm a bit concerned about those dependencies. What shall I depend on? libgl1-mesa-glx ( >= 7.6.1~rc3-1ubuntu2) and xserver-xorg-core (>= 2: ?22:20
tseliotsoren: does it already?22:21
tseliotmaybe mesa was published22:21
sorentseliot: I grabbed the binaries from Launchpad.22:21
tjaaltontseliot: something like that, yes22:21
sorentseliot: No, mesa still isn't published.22:21
sorenOh, it was /just/ published.22:22
sorenIt wasn't 10 minutes ago.22:22
tseliottjaalton: by the time nvidia is approved, builds and is published I bet mesa will be on every server in the world22:22
* tseliot hasn't uploaded nvidia yet22:23
tjaaltontseliot: as you wish22:23
* tseliot starts uploading nvidia-current22:27
tjaaltonxorg merged & uploaded22:48
* tseliot uploading nvidia-17322:54
Sarvattin our mesa 7.7, shouldnt we be bumping the libdrm-dev build-dep version to 2.4.17 because we use libdrm-radeon1?23:06
tjaaltonwell yes, but since it already depends on .15 which isn't available, we should be good23:07
tjaaltonI mean, .17 will be available and it fails to build with the current .1423:07
tjaaltonerr, doesn't even try to build23:07
tjaaltonit's in depwait23:08
Sarvattdarn flickering after resume, the latest 01-07 2.6.33-999 kernel didnt have the drm-intel-next pull in it it looks like23:11
bryyce<vorlon> bryyce: fwiw, the xorg upload for the nvidia colormap fix has also fixed my intel crash-on-lid-close bug :)23:17
tjaaltonbryyce: whaaat :)23:17
Sarvatthow the heck23:17
Sarvattoh maybe it was in 1.7.423:17
bjsniderwhat does one have to do with another23:18
tseliotcome on, don't you believe in magic? :-P23:18
tjaaltonSarvatt: yes, most likely23:18
Sarvattforgot it was a version bump in the latest upload, i didnt see how just the gamma fix woulda fixed it23:18
bjsnideri'll believe it when i can build against its header file23:18
bryyce<vorlon> heh, well, my backtrace also had some color-related stuff in it :)23:19
bryyce<vorlon>  I think the crash was specifically related to X trying to query the gamma on an output that had been turned off immediately prior23:20
tjaaltonit would be nice to verify that it's what fixed it, and add that to the mvo's patch. should help getting reviewed/ack'ed upstream23:21
tseliotall the nvidia packages are now in Lucid23:23
tseliotI'll upload the other pieces tomorrow23:24
bryycetjaalton, *nod*23:25
bryyce<vorlon> man, I'm not bisecting over this :)23:27
Sarvattyou know, tormod had a problem with that exact hunk in xserver for a few months when i was packaging up xorg 7.5 for karmic23:28
* slangasek metoo!23:28
slangasekI have this exact same bug23:28
Sarvatthe was crashing until this commit http://cgit.freedesktop.org/xorg/xserver/commit/?id=75795637c7160f1579dbe81c2d7600e85b1d141f23:28
Sarvattthere was a long discussion on the gamma problem there on xorg-devel i think, might be something interesting in there23:29
SarvattIt also contains a fix from Adam Jackson to not crash on xserver 1.7, but please note that it still doesn't work correctly on that release because the server never calls the old-style colormap setup code.23:32
Sarvattredhat still uses nv for some chipsets, wonder if they have any patches for it23:32
tjaaltonyes, http://lists.x.org/archives/xorg-devel/2009-May/000982.html23:33
tjaaltonand continued the next month23:34
Sarvattscrewing with that hunk might cause regressions on non -nv is all i was thinking, yeah thats the same chipset tormod was having problems with I think23:34
tjaaltonwe'll see23:35
tjaaltoneveryone signing off for the weekend, just the right time to upload a ton of stuff :P23:35
tjaaltonslangasek: what was your bug # again?23:36
slangasektjaalton: 49468023:37
Sarvattlooks like it only affects G80+ cards under -nv too23:39
Sarvattshifting G80+ pci ids to use vesa would probably be better if it ends up causing problems. odd i didnt get any email from xorg-devel about that patch23:42
tjaaltonwell slangasek has an intel, and it fixed the lid-closing crasher, so it's not just -nv23:42
Sarvattlooks similar slangasek - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=55445023:45
ubottuDebian bug 554450 in xserver-xorg-video-intel "xserver-xorg-video-intel: server crash on external monitor when using gnome-screensaver" [Normal,Open]23:45
tjaaltonindeed it does23:45
Sarvattdpms off with multiple monitor related maybe?23:46
slangasekall of these keywords seem to apply :)23:47
Sarvattlike I know KDE does a dpms off on lid close from tracking down another bug it had awhile back (dont know what you're using)23:48
Sarvattdo you have g-p-m set to "do nothing" on lid close?23:50
Sarvattor blank screen?23:50
Sarvatti really dont know how its all connected at the moment but you might want to try disabling activate screensaver when idle in gnome-screensaver and set g-p-m to do nothing on lid close and try it out23:53
Sarvattif it didnt happen when booting with nomodeset would also be good to know23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!