[03:43] Sarvatt, do you happen to understand the rationale behind the choices of alternatives in fglrx? [03:44] bjsnider: no i dont, thats why i dont touch it lately [03:44] i guess i shouldn't try, but i'd like to get it into x-updates [03:45] i just don't understand why some of the libs were chosen for alternatives while others weren't [03:45] What libs are these? [03:45] bjsnider: you know you can build source debs from the installer right? [03:45] well [03:45] its really easy to install your own fglrx from their website, thats the other reason i dont [03:46] Huh. This laptop has a single combined headphone/mic port. How annoyingly useless! [03:46] third reason is its a pain in the butt to verify the kernel module builds, thats where things always go wrong [03:47] RAOF, usr/lib/libaticalxx is strange [03:47] where xx is rt and cl, alternatives are in play, but dd and libatiuki are not covered [03:47] and this is where two new opencl libs have appeared [03:48] oh thats opencl stuff, i bet they put that in there themselves without alberto's help [03:48] so i don't know if they should be included, but it seems like they should because amd has a now-obsolete opencl package that would have those files and also nvidia provides a libopencl.so.1 [03:49] but nvidia's libopencl is not covered by alternatives... [03:49] bjsnider: tseliot is going to upload 11.11 probably tomorrow, hopefully they dont have much package churn after that so it should be easy for a few months :) [03:49] Sarvatt, phoronix says the december release is a big change too [03:50] the source package is now too big to fit on a cd [03:50] j/k [03:50] bjsnider: yep you're right, ugh [03:50] Sarvatt, for oneiric? [03:50] just looked at the betas [03:50] bjsnider: nah precise but nothings changed really [03:50] easy to nab it :) [03:51] 4 new libs in the december ones [03:51] i thought alternatives existed to stop to packages from installing the same file, thus overwriting each other [03:51] but all of these laternatives are ati-specific stuff, so why do they need alternatives? [03:51] They don't. [03:52] that's not too confusing or anything [03:52] why are laternavites used in fglrx then? [03:53] nvidia ships libgl, so it makes a lot of sense there [03:53] all of this stuff is libati* or amd* [03:54] It probably shouldn't be alternatived. [03:54] so these packaging scripts are overcomplicated for no apparent reason? [03:55] That would seem to be the case? [03:56] Sarvatt, are the 4 new libs going to add 200mb more size this time? [03:57] the graphics driver is bigger than the friggin' kernel [03:57] and it's not even shipping its own gl [03:59] thier code must be shared cross-platform like nvidia === chrisccoulson_ is now known as chrisccoulson [10:19] wacom 0.12.0 uploaded === soreau_ is now known as soreau [10:53] bryceh: might be the time to change versions-current to show precise? [11:18] tseliot, hello [11:19] ricotz: hi [11:19] tseliot, how is it going with fglrx? [11:19] I haven't updated the driver yet. I need to upload a fixed nvidia-common and jockey first then I'll think of fglrx (my scripts should be mostly ready) [11:20] ok, i will be patient then :) [11:20] ricotz: wacom is uploaded though [11:21] tjaalton, good [11:22] support for intuos4 oleds should now be in precise.. will test once it's built [11:25] tseliot, do you thought about getting cuda in repos yet? [11:25] ricotz: cuda for what? [11:26] tjaalton, unfortunatelly i dont have a wacom device for testing [11:26] tseliot, libraries like nvidia-texture-tools can use it for example which isnt packaged yet [11:27] ricotz: is it in debian already? [11:27] tseliot, since it is already available in debain syncing it would be nice, but it isnt compatible with the nvidia-driver packaging of ubuntu [11:28] ricotz: oh, I'll have a look at the debian package then, and see what needs to be done [11:28] tseliot, do you think it is possible to adapt the nvidia packaging [11:29] they splitted up all libraries in their own debs though [11:29] ricotz: it depends. I'll know only when I see it [11:29] tseliot, ok, thanks [11:30] ricotz: no worries, i have one, and an Aiptek (waltop) [11:31] i packaged cuda locally for the university where i used to work [11:31] there were people doing some research with it [11:35] ah [11:41] there's this sdk that you had to initialize so that it'd be linked to from your home directory [11:41] can't remember, strange stuff :) [12:04] can someone help me to get FGLRX drivers installed and working on HP ProBook 4530s with Intel Sandy Bridge + AMD HD6490 graphics? [12:04] When starting Xserver with FGLRX installed, XServer get segmentation fault [12:06] here is the log: http://pastebin.com/hsnCw47g === soreau_ is now known as soreau [15:02] tseliot, i was looking at the fglrx scripts last night and i don't understand the choices of which files to use with alternatives [15:03] they all look like amd-centric stuff, so why are they in danger of overwriting anything? [15:04] bjsnider: I'm not sure I understand what you mean [15:05] well i thought the reason for using alternatives was to make sure file a doesn't overwrite file b of the same name also provided by another package? [15:05] but all of this stuff is called libati* or amd* [15:06] bjsnider: right, and we have 2 flavours of the same driver [15:07] it's just a case that they cannot be installed at the same time [15:07] (because of hybrid graphics) [15:07] you have 2 versions of fglrx? [15:08] fglrx and fglrx-updates [15:09] why not just make the packages conflict with each other? [15:10] does anyone know how can I fix a problem that I described ? [15:11] don't use fglrx [15:12] hybrid graphics fail [15:13] bjsnider: I did that, when I realised that they couldn't be installed at the same time [15:13] jcristau: that's definitely a solution ;) [15:14] but if they conflict then why are alternatives needed? [15:14] * tseliot uses only open driver on his main pc [15:14] that and don't buy silly hybrid graphics. [15:14] *drivers [15:14] bjsnider: libGL, and other stugg [15:14] *stuff [15:15] nvidia provides its own libgl [15:15] and so do mesa and fglrx [15:16] this way you can install both nvidia and fglrx at the same time [15:16] (using only one though) [15:16] well, it worked on SLED 11 :S [15:17] Milos_SD: I don't know what problem you're facing but did you file a bug report about it? [15:17] tseliot, http://pastebin.com/hsnCw47g [15:17] that's Milos_SD's pastebin [15:18] right, it's trying to load both intel and fglrx -> fail [15:19] Milos_SD, have you got a switch to turn off one chip or the other? [15:19] in theory that should work [15:19] bjsnider, there is only switch to turn ATI off [15:19] good [15:19] and that intel kms is probably being used [15:20] can fglrx that charge if I disable modseting for intel? [15:20] that is the only think I didn't try [15:20] a lot of people don't even have a switch [15:20] thing* [15:20] Milos_SD: there's a script you can try to switch [15:21] it is not actualy a switch... it is option to disable switchable graphics (it disables ATI totaly) [15:21] switchable graphics : ON or OFF... nothing else [15:21] :) [15:21] Milos_SD: so, if you want to use both cards [15:22] (in the BIOS) [15:22] and experiment with the fglrx driver [15:22] you can do this to use the AMD card: [15:22] sudo /usr/lib/fglrx/switchlibGL amd [15:22] sudo /usr/lib/fglrx/switchlibglx amd [15:22] and restart [15:22] or [15:23] sudo /usr/lib/fglrx/switchlibGL intel [15:23] sudo /usr/lib/fglrx/switchlibGL intel [15:23] to use only the intel card (without having to remove fglrx) [15:26] Milos_SD: if this ^ doesn't help, feel free to file a bug report [15:29] problem is that, I think there are few bug reports about this :) [15:31] Milos_SD: I don't think this is officially supported by AMD but I do what I can to help === chrisccoulson is now known as no_it_is_not_fix === no_it_is_not_fix is now known as chrisccoulson [15:37] tseliot, it doesn't work... it is the same as doing: sudo aticonfig --px ddx or --px idx [15:38] and switchlib doesn't even switch libs :) [15:38] Milos_SD: how so? [15:38] I mean, how are you so sure that it doesn't switch libraries? [15:38] in xorg log it says something about not right libs are loaded [15:39] are you using oneiric? [15:39] 11.10 [15:39] ? [15:39] yes [15:40] ok, so, do an update-alternatives --display x86_64-linux-gnu_gl_conf (if you're using Ubuntu 64 bit) before and after those two commands [15:41] things should change. The fact that the driver segfaults is a different issue [15:41] oh and sudo aticonfig --px ddx or --px idx call those two scripts [15:42] (which I wrote) [15:42] yes I know that... and after I use aticonfig --px idx I can't use aticonfig at all anymore [15:42] libGL is missing [15:43] Milos_SD: oh, I think I know what's going on... [15:44] no wonder it's missing [15:44] I should've updated the powerXpress alternative with multiarch paths for mesa... my bad [15:45] I'm going to upload a new upstream release with a fix anyway [15:45] :~$ cat /usr/lib/pxpress/ld.so.conf [15:45] /usr/lib/mesa [15:45] /usr/lib/pxpress/lib [15:45] /usr/lib32/mesa [15:45] /usr/lib32/pxpress/lib [15:45] wrong ^ [15:46] ;) [15:46] btw, I need to create /usr/lib64 directory and then copy fglrx folder from /usr/lib/ in it to make aticonfig --initial -f work at all [15:47] Milos_SD: it's best if you don't copy things manually, otherwise things will break on next update [15:48] well I do that when I install 11.10 version of fglrx from amd site... but it has to be done for fglrx-updates from repos too [15:48] and I think for fglrx package too [15:48] Milos_SD: that's because I maintain the scripts for all of them ;) [15:49] therefore if something is not fixed in my packages in ubuntu it's likely that it's not fixed in the amd installer [15:50] for fglrx package (not the -updates one) have that bug fixed in changelog, but it isn't realy fixed :) [15:50] I'll check that and make sure that it's really fixed [15:50] thanks for reporting the issue [15:51] so, that is the main problem that Xserver is segfaulting here? [15:54] main reason* [15:54] Milos_SD: it could be [15:54] * tseliot -> phone call === soreau_ is now known as soreau [17:11] tjaalton, right; will try to get that updated today [17:12] bryceh: cool, thanks [17:39] multiarch with PPAs is really proving to be unfun because i386 is always backed up more than amd64 and you get http://paste.ubuntu.com/741401/ for a few hours every day [17:39] accept that and wine silently stops working [18:14] Sarvatt, thanks for updating right drivers ;) [18:15] the right drivers? [18:15] the ones which failed so far with xserver git master [18:16] didnt follow their changes but maybe they got fixed [18:17] oh my script updates every driver whenever there are new updates in upstream git, they must be fixing it :) [18:17] yeah ajax fixed a bunch up it looks like [18:17] its screwed up on mga though, i have to do that one manually [18:17] is that broken? [18:18] ricotz: does geode build on master? [18:18] or openchrome [18:18] mga built [18:19] geode i havent in the ppa though [18:19] https://launchpad.net/~ricotz/+archive/unstable/+packages [18:22] so just vmmouse still [18:23] might be able to fix that up, lets see [18:24] i am copying the missing one, i just grabbed the driver from the precise pocket [18:53] oh hell [18:53] spent the past half hour fixing up vmmouse then it hit me [18:53] ajax was fixing the upstream drivers up, check fedora [18:53] http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-drv-vmmouse.git;a=blob;f=0001-Deal-with-opaque-InputOption-types-in-ABI-14.patch;h=ef4a765a4839bb5cd3e8ac8e7fc927c1c8fd952d;hb=9b1097ff9fc1a828eb8e899c5ed4c8f006b88574 [18:54] ricotz: new vmmouse incoming :) [18:54] Sarvatt, nice ;) [18:55] unfortunatelly wacom failed against all odds [18:57] ricotz: did you check fedora? [19:00] yeah, it might work with git master [19:00] wacom said so too ;) [19:01] ricotz: you could always override_dh_auto_test: [19:01] dh_auto_test || echo "Test suite failure, but keeping on anyway" [19:01] :P [19:02] i see, havent looked at it closely while i dont really need it === JanC_ is now known as JanC