=== Amaranth_ is now known as Amaranth === verbalshadow_ is now known as verbalshadow === Amaranth_ is now known as Amaranth === ara is now known as ara_ === ara_ is now known as ara [10:13] aw... i can switch user or get into a guest session :( > Bug 506510 [10:13] Bug 506510 on http://launchpad.net/bugs/506510 is private [10:13] cant* [10:16] bdmurray: I can't find the button to make this report ^^ public [10:16] or ara ^^ ? [10:17] tseliot, I'll review it and make it public [10:17] ara: thanks [10:19] tseliot, are you part of the bugcontrol team? [10:19] ara: yes, I think so [10:20] yep [10:20] https://launchpad.net/~albertomilone [10:20] tseliot, then, you should see an "edit" icon right of the message "This bug is private" [10:21] tseliot, can't you see it? [10:21] ara: no icon to the right of that message [10:21] tseliot, weird [10:23] tseliot: made it public [10:24] ara: I guess it's some bug in google chrome [10:24] tseliot, it might be :) [10:24] tseliot, I am making it public now [10:24] ara: thanks [10:25] it works well in opera [10:25] ara: just did it :) [10:25] so it was definitely a bug in chrome [10:25] sorry for the noise [10:25] tseliot, np :) [10:31] tseliot, I have to double check later (right now I am working on something else), but Xorg crashes (and doesn't come up) after resume [10:31] ara: with what driver? Nvidia? [10:32] tseliot, yes, Nvidia (although I've only tested it with Nvidia) [10:33] ara: BTW I don't know if you've experienced bug #506547. I you did, I'm working on it [10:33] Launchpad bug 506547 in mesa "Some GL apps won't run: libGLU.so.1: No such file or directory" [High,In progress] https://launchpad.net/bugs/506547 [10:34] tseliot, no, I haven't seen that one, but I'll subscribe to it, just in case :) [10:34] good [10:35] tseliot, if you see any bugs you might be interested in me to test them or you feel I should know, feel free to subscribe me [10:35] ara: ok, thanks a lot [10:35] tseliot, thanks to you! [10:35] :-) [10:35] * ara hugs tseliot [10:36] * tseliot hugs back ara [11:42] This will sound totally crazy, but there's a valid reason for wanting to do it (fat client chroots on LTSP): [11:42] Is it possible to install ALL proprietary drivers (e.g. nvidia, ati) on a system, and for an initscript to look up the pci id and write the appropriate xorg.conf, if needed? [11:42] The goal is to have an image (imagine something like a live cd) that can boot on most systems and include 3d acceleration out of the box. [11:42] The image will be build locally on each site by a script, so I'm not concerned about redistribution problems. I'm mostly worried about dependencies / library conflicts etc. [11:42] Do you think that it's possible to create such an image? [11:43] Thanks in advance for any input. [11:44] don't we go without a xorg.conf nowadays? [11:44] install all the drivers, have a blank xorg.conf and then start the server? [11:44] won't that work? [11:44] I think that for proprietary drivers, a minimal xorg.conf is needed, that contains the driver name [11:44] Otherwise the open source version will be used. [11:45] oh isit? [11:45] I *think* so :) [11:45] Also, I'm not sure if the opengl libs will work. E.g. nvidia installs its own opengl libs versions, and then the client has an ati. [11:45] alkisg, I know that if y ou have intel drivers and nvidia drivers installed at the same time...the usual outcome is that the system works but the desktop is upside down and in reverse.... [11:45] er [11:45] upside down? [11:45] coz_: right, I've seen that. I can work around it by globally disabling compiz. [11:46] hyperair, yep [11:46] alkisg, ah cool [11:46] coz_: like literally? [11:46] alkisg, it has always interes [11:46] interested me that issue [11:46] hyperair, very litterally [11:46] literally [11:46] * hyperair gapes [11:46] coz_: do you think there would be conflicts in other libraries? [11:46] E.g. nvidia-96 would conflict with nvidia-185? [11:47] alkisg, not sure but considering the outcome of that senario I wouldnt doubt it [11:47] alkisg, oh [11:47] alkisg, mm [11:47] alkisg, not sure [11:47] oh yeah nvidia-96 would definitely conflict [11:47] Ouch [11:48] alkisg, I think we have seen issues even with nvidia an ati drivers installed [11:48] alkisg, why are you thinking this by the way? [11:48] coz_: it's a fat client scenario [11:49] alkisg, oh! [11:49] Something like a live cd is served over the network [11:49] ah i see [11:49] So the clients only use that "cd" as a disk, but they use their own CPU/RAM etc [11:49] alkisg, sounds interesting... I dont envy what you are trying to do though [11:49] something like nfs root? [11:49] hyperair, yup. [11:49] coz_: it currently works FINE :D [11:49] heh [11:49] alkisg, oh cool :) [11:49] * alkisg loves the new LTSP fat client plugin :) [11:50] alkisg: do you want to install all proprietary drivers or do you want to use them all at the same time? [11:50] tseliot: I want each client to use only the appropriate driver [11:51] so not installed but avilable [11:51] So if an initscript can somehow handle it, I'm fine! [11:51] available [11:51] with the new alternatives system in lucid you'll be able to install them all. Then set the alternative to whatever you want to use, change xorg.conf and reboot [11:51] very cool [11:52] tseliot: what about nvidia-96 and nvidia-185? [11:52] ideally this should just work (without any xorg.conf) if I fix the nvidia and fglrx autoloading patches [11:52] hyperair: nvidia-185? [11:52] nvidia-current = 190 [11:52] (nvidia-current, I just said 185 to make a contradiction with -96...) [11:52] oh whoops [11:53] tseliot: sorry, i'm outdated. [11:53] nvidia-current, nvidia-173 and nvidia-96 (and soon also fglrx) can all be installed at the same time [11:53] Yey!!! /me hugs tseliot!!! :) [11:53] eh that's interesting [11:53] which is one of the reasons why I implemented the alternatives system ;) [11:54] tseliot: out of curiosity, have you seen any reports of flickering screens with nvidia-96? [11:54] I should document how all of this works [11:54] * hyperair is pretty annoyed with his -96 desktop [11:54] * alkisg has flickering screens since karmic [11:54] (with nvidia) [11:54] heh [11:54] i've had flickering screens since... [11:54] hyperair: I'm been too busy with mesa in the last few days ;) [11:54] jaunty? [11:54] intrepid? [11:54] tseliot: no i meant, further back. [11:55] tseliot: reports from a few releases back [11:55] * hyperair kicks his desktop [11:55] hmm... I wouldn't know. I think I remember something about that [11:56] i'm this close to scrapping GNOME and nvidia on that desktop, and just going nouveau or nv and one of those minimalist WMs [11:56] hyperair, have you tried gnome-shell? [11:56] * hyperair runs that desktop headless most of the time. [11:57] coz_: yes. and i hate it. [11:57] hyperair, right now it is a little resource intensive with video [11:57] hyperair, :) [11:57] coz_: that's not the point. [11:57] coz_: metacity has flickers with the nvidia driver. [11:57] o0 [11:57] coz_: gnome-shell won't work at all without 3d. [11:57] mm [11:57] gnome-shell, pah. should be gnome's-hell or something >_> [11:57] i want my compiz. [11:58] :) [11:58] hyperair, wait for 0.9.x compiz to release [11:58] hell yeah, i'm waiting. [12:01] hyperair, although that video about gnome shell and clever windows was real appealing [12:01] clever windows? [12:01] I have no idea if clever windows will be implimented or even considered [12:01] hyperair, yeah google ...... clever windows video >>>>>> [12:03] oh yeah i think i've seen this before [12:04] hyperair, although compiz has most of those features except that litte tab on the left and right for minimizing etc [12:04] righ [12:04] t [12:37] what do i have to do to install the current version of nvidia? all methods i tried so far did not work [12:38] i tried: apt-get install nvidia-current and installing via jockey [12:38] then i ran nvidia-xconfig [12:48] knittl: jockey doesn't work with nvidia yet [12:48] tseliot: ok, i see. what about apt-get? [12:48] apt-get install nvidia-current and then nvidia-xconfig and reboot [12:48] and that's it [12:48] do i have to install the modaliases (the common package)? [12:53] knittl: that's only for jockey [12:53] you might need it in the future [12:53] ok, but right now it's enough to install nvidia-current without anything else? [12:54] yes, that and nvidia-xconfig [12:55] yep, for creating the xorg.conf of course [12:55] good, i'll give it another try [13:10] is it known that nvidia is broken on latest xorg updates? [13:24] gnomefreak: define "broken" please? [14:29] tseliot: still no luck, looks like X is crashing [14:31] knittl: what happens exactly? [14:32] here is what i did this time: purged everything related to nvidia (apt-get purge nvidia*), searched in aptitude for nvidia, removed libvdpau, removed all xorg.conf* files, rebooted. service stop gdm, apt-get install nvidia-current, nvidia-xconfig, checking the successful creation of xorg.conf (yep, it's there, with driver = nvidia), rebooting. screen flickers early on (plymouth?), gdm gives warning that graphics driver is broken -> start in low resolution [14:32] describe the symptoms please [14:33] knittl: can I see your /var/log/Xorg.0.log and /var/log/Xorg.0.log.old, please? [14:33] i see text on the console (fsck, ureadahead terminating), then screen goes black, screen flickers, gdm error message appears [14:33] sure, just a second [14:35] http://knittl.is-a-geek.net/public/Xorg.0.log{,.old} [14:41] knittl: maybe the kernel module wasn't built. What does this command say? dkms status [14:41] nvidia-current, 190.53, 2.6.32-10-generic, i686: installed [14:41] did the kernel module build ok when you reinstalled? if so, try sudo update-initramfs -u and reboot again? I need to do that pretty much every time I purge/reinstall nvidia, the first boot after is always failsafe [14:42] hrm [14:43] knittl: also make sure that no other nvidia drivers (especially the ones from unofficial PPAs) are installed [14:43] tseliot: no, i purged nvidia before, and i deaktivated all ppas. i also run several updates [14:44] apt-get purge nvidia* should have taken care of that, have to reinstall nvidia-common manually after that though [14:44] dmesg might have something interesting [14:44] that's only needed for jockey and jockey does not work yet with the new nvidia. that's what i was told before [14:44] * tseliot nods [14:44] dmesg ^^ [14:45] same url, file dmesg [14:46] ara, slangasek: I have worked on #506547. I have uploaded my fix for mesa to my PPA: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements [14:46] can you test it please? [14:48] the tests that I've run here so far i.e. building mutter and testing blender went well: http://pastebin.ubuntu.com/356082/ [14:49] oh, it's 7.7-0ubuntu5~proprietaryppa1 [14:49] and it's still building [14:50] tseliot, I will test it when it's done [14:51] ara: ¡Muchas gracias! [14:57] err. "invalid "install -d" command" [14:57] ? [14:57] ah. because $(INSTALL) isn't set anywhere, i guess [14:58] yep [14:58] and it was useless anyway [14:59] ack [15:07] thanks for reviewing my commit [15:29] ara: the packages are ready (just FYI) [15:30] tseliot, OK, I will test them as soon as I have time (ISO testing takes lots of time) [15:30] ara: sounds good, thanks === \vish is now known as vish [16:12] slangasek: in addition to fixing #506547 ^^ I also sent you something to put in the release notes (which, of course, you can modify as you like) [16:15] tseliot: feel free to edit https://wiki.ubuntu.com/LucidLynx/TechnicalOverview directly (I won't be able to look at this for several more hours) [16:17] slangasek: ah, good. Just to be clear, I fixed the bug but haven't uploaded anything yet (see above) [16:17] any reason not to upload, if it's fixed? [16:19] slangasek: I was waiting on QA to test it (in addition to my tests). If you want me to upload it now, I'll do it though [16:19] tseliot: ok - more testing is good :) [16:19] * tseliot nods [16:20] slangasek: BTW I have evidence that things go well with the fix: http://pastebin.ubuntu.com/356082/ [16:21] I noticed that a simple 'xrandr' auto-activates the external monitor on my laptop. prior to kms this was not the case. Is this behavior intended or a bug? [16:21] tseliot: goody! [16:21] :-) [16:23] siretart`: my guess would be, xrandr tells the kernel to probe the connector, it then detects that the external monitor is connected, sends an event to tell userspace that, and something (gnome?) enables it [16:24] jcristau: well, a friend confirmed that the same behavior appears in debian/unstable as well, and that it occurs since switching to kms [16:24] siretart`: what jcristau says is correct, at least if you're using gnome [16:25] because gnome-settings-daemon gets the hotplug event [16:25] tseliot: what part of gnome is responsible for that? [16:25] ^^ [16:26] xrandr --current wouldn't do that, fwiw [16:26] I noticed another bug as well: if you open an opengl application (like glxgears) and enlarge the window to more than 2048 (roundabout) pixels, the intel inkernel gem locks up and requires a reboot [16:26] ideally cable hotplug events are useful but in some cases (e.g. VGA cables) they are triggered only after running xrandr manually [16:26] or probing in any other way [16:27] this is particularily painful when connecting a 1920x1200 display and typing 'xrandr' in a shell: instant lockup [16:28] fun... [16:28] jbarnes: ^^ [16:28] siretart`: the bug about going beyond 2048 was fixed in mesa 7.7 and the latest intel [16:28] tseliot: I guess gnome-settings-daemon shouldn't call xrandr without --current then, right? [16:28] let me find the bug [16:29] gnome-settings-daemon doesn't call xrandr at all.. [16:29] siretart`: no, it doesn't call xrandr at all. When you call that, it cause a reprobe and you get that event [16:29] and then g-s-d enables the external screen [16:30] https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/503255 is the bug I filed [16:30] Launchpad bug 503255 in xserver-xorg-video-intel "[i945] querying information on external monitor with xrandr hangs gpu when compiz is active" [Medium,Triaged] [16:30] tseliot: I'd consider g-s-d auto-enabling the external screen a bug. can this behavior be disabled by a configuration change? [16:31] siretart`: I'm not sure if it's the same bug but this one looks similar: https://bugs.freedesktop.org/show_bug.cgi?id=23718 [16:31] Freedesktop bug 23718 in Driver/intel "[945GME] attaching external monitor causes black screen, with Compiz Fusion in Karmic" [Critical,Resolved: fixed] [16:31] siretart`: you can always disable g-s-d's randr plugin from gconf [16:31] and it's not a bug, it a feature ;) [16:32] a feature that bugs you but still a feature :-P [16:32] I'd prefer to have the behavior consistent to earlier releases of ubuntu, TBH [16:33] bug the gnome people then, maybe? [16:39] with this explanation, I think the defect report is "g-s-d's xrandr manager changes display configuration on probing monitors" [16:39] thanks for clearing this up! [16:40] siretart`: auto-enables would be more appropriate than "changes", I guess [16:40] ok [16:40] and it's an upstream decision [16:40] siretart`: you can discuss it with federico1 [16:41] who happens to be upstream ;) [16:41] tseliot: you wrote earlier that the bug with gl frames beyond 2048 was fixed in "latest intel". is lucid's 2.9.1-1ubuntu1 recent enough? [16:41] federico1: around? see ^^ [16:44] siretart`: good question. If it's not, we'll pull it [16:45] hm. I think I'll just dist-upgrade my laptop and test it [16:47] ok, good [16:48] tseliot: the freedesktop bug 23718 is not related to this issue. the kernel oops trace looks different [16:49] Freedesktop bug 23718 in Driver/intel "[945GME] attaching external monitor causes black screen, with Compiz Fusion in Karmic" [Critical,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=23718 [16:49] in fact, I don't get any trace at all [16:49] well, maybe related, but not the same [16:51] siretart`: can you upstream your bug report (on freedesktop), please? Intel should know whether it's the same problem or not [16:52] but yes, dmesg looks different in your bug report [16:54] probably not today, will need to defer that to tomorrow [16:58] ok === yofel_ is now known as yofel [17:32] siretart`: hmm, what was the problem_ [17:32] ? [17:33] federico1: g-s-d auto-enabling the external screen on hotplug events [17:34] tseliot: oh, yeah, I intend to do something about that [17:34] which he gets after using the "xrandr" command (which causes a reprobe) [17:34] I want to just bring up gnome-display-properties so that you can setup the monitors, or ask you "you have a new monitor - what do you want? [clone] [extend] [custom]" [17:35] tseliot: BTW, I'm reworking the handling of the XF86Display hotkey, so that we bring up an OSD window with options instead of having you guess what the program did... [17:35] federico1: that feature is more than welcome [17:36] actually both features are [17:36] federico1: I think a small dialog would work for the hotplug event case, as you suggested [17:37] tseliot: yeah, maybe the same OSD window with an extra label, "you just plugged a monitor; please pick one of the following options" [17:38] tseliot: when I'm done with that OSD, I want to merge the moblin patches for transformations [17:38] federico1: either way you might want to have this in the hotplug case: [clone] [extend] [custom] [no action] [17:39] yeah [17:39] sounds good! [17:39] federico1: that would be great. What would be even better is if transformations were implemented directly in mutter [17:40] so as not to get a performance hit when scaling [17:42] slangasek: BTW when I get the ok from QA shall I ask you before I upload? (because of the freeze) [17:43] tseliot: no, just go ahead with uploading then [17:43] slangasek: ok, thanks [17:46] tseliot: you mean, have the compositing manager transform stuff instead of doing it with xrandr transformations? [17:46] federico1: yes, exactly [17:47] interesting [17:47] hmm [17:47] that should be faster [17:47] so [17:48] tseliot: regardless of the speed (which *is* an important concern), the CM would indeed give us more flexibility. I'm not sure that you can have xrandr transformations just do "I have a 1024x600 netbook; make it show on my 1024x768 projector with two black bars at the top and bottom" [17:48] maybe you can; I'm not sure [17:49] federico1: I'm not sure about the bars. What I know for sure is that you can make clone screen work using different resolutions by scaling the content of one of the 2 screens. If they aspect ratio is different, things will look slightly deformed but still good IMO [17:50] bryyce, hey ... we have a bunch of people not being able to boot to X with modesetting turned on, it seems to have occcured with an x/mesa update today ... ringa bell? [17:50] (on i915) [17:50] tseliot, ^^ [17:50] apw: ls -l /usr/lib/xorg/modules/extensions/ [17:51] tseliot, what am i looking for? [17:51] apw: libdri.so and libglx.so [17:52] they are both 2010-01-12 11:12 [17:53] apw: ok, it must be something else then. Can I see your /var/log/Xorg.0.log, please? [17:54] apw: err, the one with KMS [17:55] ls -al /usr/lib/xorg/modules/extensions/ [17:55] total 148 [17:55] drwxr-xr-x 2 root root 4096 2010-01-13 09:50 . [17:55] drwxr-xr-x 7 root root 4096 2010-01-13 09:50 .. [17:55] tseliot: yeah, maybe a bit of distortion is acceptable (like 4:3 NTSC on widescreen TVs) [17:55] -rw-r--r-- 1 root root 17920 2010-01-12 11:12 libdbe.so [17:55] -rw-r--r-- 1 root root 13784 2010-01-12 11:12 libdri2.so [17:55] -rw-r--r-- 1 root root 92336 2010-01-12 11:12 libextmod.so [17:55] -rw-r--r-- 1 root root 9708 2010-01-12 11:12 librecord.so [17:55] king@hpmini:~$ [17:56] cking: that's wrong, you're missing those 2 modules. sudo apt-get install --reinstall xserver-xorg-core and it should be ok [17:56] tseliot, will try that - hold on [17:58] tseliot, we have a three machines in this one room with this symptom [17:58] apw: ubuntu5 of xserver-xorg-core should have fixed that [17:59] tseliot, ok checking :) [18:01] tseliot, pgraner has ubuntu5 [18:01] and its not working for him, cking reports a --reinstall fixing it [18:02] apw: weird, the preinst should have taken care of that [18:02] slangasek: ^^ [18:03] pgraner, has ubuntu5 and 4 files in /extensions [18:04] tseliot, an upgrade from ubuntu4 to ubuntu5 of that package did work for smb on another machine [18:05] ie we went from 4 to 6 files in /extensions [18:06] that's interesting [18:06] cking, went ubuntu5 without it, and reinstall made it work# [18:06] s/went/was on [18:06] we have one box on u5 with out those files, need anything from it? [18:07] apw: what version of the same package was installed before ubuntu5? [18:08] see /var/log/apt/term.log [18:09] tseliot, cking he did just the apt-get --reinstall xserver-xorg-core and after that he had ubuntu5 so i assume he had u5 before that [18:09] and he confirms the logs show u5 as installing this AM [18:10] and pgraner is in the same place, but before the reinstall, ie with u5 and not working with 4 files in /extensions [18:10] apw: right. And what did he have before installing u5? Was it u4? [18:10] or u3? [18:10] checking [18:11] cking was on u2 -> u5 [18:12] pgraner, reports from u2 -> u5 also ... and he says he has been updating daily [18:15] apw: what does this command say? update-alternatives --display gl_conf [18:15] tseliot, on a good or bad one [18:16] tseliot, update-alternatives --display gl_conf [18:16] gl_conf - auto mode [18:16] link currently points to /usr/lib/mesa/ld.so.conf [18:16] /usr/lib/mesa/ld.so.conf - priority 500 [18:16] slave gl_libraries: /usr/lib/mesa [18:16] slave xorg_extra_modules: /usr/lib/xorg/x11-extra-modules [18:16] Current `best' version is /usr/lib/mesa/ld.so.conf. [18:16] cking: on a bad one [18:17] i.e. one that doesn't have those 2 modules yet [18:17] tseliot, coming [18:17] pgraner@zorak:~$ update-alternatives --display gl_conf [18:17] gl_conf - auto mode [18:17] link currently points to /usr/lib/mesa/ld.so.conf [18:17] /usr/lib/mesa/ld.so.conf - priority 500 [18:17] slave gl_libraries: /usr/lib/mesa [18:17] slave xorg_extra_modules: /usr/lib/xorg/x11-extra-modules [18:17] Current `best' version is /usr/lib/mesa/ld.so.conf. [18:19] slangasek: ok, so the alternative was removed and our fix (in the preinst script) worked but the modules were not installed [18:19] smb has an installation on ubuntu2 level, in case we want to test the update [18:19] apw, pgraner, cking: thanks [18:20] apw: oh, good [18:22] * tseliot -> off for a bit [18:24] tseliot, we note that these files were links in u2, but in u5 fixed they are real files [18:26] apw: yes, as I had to move the alternatives from the xserver to mesa. However xserver-xorg-core ubuntu4, when removed, failed to remove its alternative thus preventing the new xserver-xorg-core from installing the real files [18:27] tseliot, presaumably as we never has u4 in there all apw: well anything <= ubuntu4 failed to remove the alternative [18:28] and the output that you gave me, shows that the alternative was removed by u5 [18:29] its seems odd that we ended up with nothing [18:31] * tseliot nods [18:40] i think we really need powersave=0 to be the default i915 module parameter in lucid over 1 it is now [18:40] +1 [18:42] dont have any hope this is going to be fixed on 2.6.32 ever, its really experimental and even with the remove render reclock support added it's still need it to fix flickering [18:43] can't enable it globally because it breaks 2.6.31 kernels because it wasnt a module parameter then [18:46] tseliot: are there still known issues with mesa? [18:53] on line 46 of drivers/gpu/drm/i915/i915_drv.c just change unsigned int i915_powersave = 1; to unsigned int i915_powersave = 0; -- would be easy to fix at least [18:53] Sarvatt, can you file a bug against linux requesting this, and sub me and steve conklin? [18:54] sure, i'm on my phone now but will when I get home, theres probably hundreds of bugs it'll fix [18:54] fedora and debian are both doing it [18:57] fedora too? didn't see that. [18:58] yeah dave airlie was complaining about how everyone has to do it on dri-devel/lkms [18:58] hundreds of bugs? nice [18:58] [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS thread [18:59] Sarvatt: yeah i read that. i just can't find that in fedora cvs [18:59] might be me being blind [18:59] or not looking in the right place [18:59] sebner: bug #506547, which is fixed in my PPA and in git: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements [18:59] Launchpad bug 506547 in mesa "Some GL apps won't run: libGLU.so.1: No such file or directory" [High,In progress] https://launchpad.net/bugs/506547 [19:02] tseliot: exactly. thanks :) [19:10] sebner: if you want to try it and give feedback (no reboot is required) that would be very welcome [19:12] hi [19:13] tseliot: done already + fixing the issue (at least for me) [19:13] i have a 3dconnexion spacenavigator, and it is detected as a mouse by X.org [19:13] but i would like to prevent that, because it needs a special driver [19:14] i tried to do that using a fdi file in the hal policy directory, but that doesn't help [19:14] can i do something about that? [19:17] sebner: great news. Thanks for testing [19:18] tseliot: thanks for fixing ;) [19:18] or is there another channel i can ask better? [19:19] wind-rider: lucid? [19:19] jcristau: indeed [19:19] then X doesn't use hal [19:20] you can run xinput float to stop it from moving the mouse [19:20] jcristau: oh, you're right [19:20] jcristau: i'll try that [19:20] where is the id you get from xinput list [19:21] Hi gentlemen [19:22] Apparently on lucid, i915 + kms makes your screen corrupted, and eventually frozes totally the display, is it known ? [19:22] if I start with i95.modeset=0 I have no issue [19:23] what hw? [19:23] jcristau: that works, thanks! i'll put it on the launchpad page for the new spacenavd package [19:23] wind-rider: 'xinput set-prop "Device Enabled" 0' should also work. i'm not sure which one is more correct. [19:24] jcristau: the first thing you said was good enough, at least :) thx! [19:24] np [19:25] jcristau, GM965/GL960 (8086:2a02) [19:26] should I report, and against which component (intel, xserver)? [19:31] baptistemm_: probably unrelated but what does this say? ls -l /usr/lib/xorg/modules/extensions/ [19:31] -rw-r--r-- 1 root root 17920 2010-01-12 12:12 libdbe.so [19:31] -rw-r--r-- 1 root root 13784 2010-01-12 12:12 libdri2.so [19:31]