[00:00] So the basic noob question is how do I edit the package? Or can I magically make the dkms tool add it for me? [00:01] Why don't you add the udev rule in the package which installs the dkms source? [00:02] Yeah that was my plan, but I do know how to edit the .deb file? [00:02] do not know* [00:02] Why would you want to edit the .deb file? Which .deb file? [00:03] Right noob [00:03] the packaging is all contained in the debian/ directory and you want to edit stuff there to alter how the package is built, debian/rules is what builds the package from source and if you want to add a udev rule that you have already you should be able to just add it as debian/vmwgfx.udev (replacing vmwgfx with whatever your source package name is) [00:03] okay [00:04] right the problem is that I used dkms to generate the package for me, it did all the debian magic. [00:04] nice, i've never even heard of dkms mkdeb before [00:04] it generated a source package for you? [00:04] yeah [00:04] you should be able to dpkg-source -x foo.dsc to extract it [00:07] I don't have a *.dsc file, only a .deb [00:08] ah looks like you need mkdsc instead of mkdeb to make a source package that you can go in and edit after [00:10] Ah.. [00:14] Sarvatt: okay edited [00:15] you'll probably need to name it foo-dkms.udev since it looks like it defaults to that package name [00:16] debian/foo-dkms.udev rather [00:20] after you edit the packaging you want to debuild -S -sa to make a new source package to do something with, or debuild -uc -us -b to make a .deb again (not sure what you're doing with it) [00:25] oh yay a mail server! [00:26] sudo apt-get purge postfix bsd-mailx :P [00:26] hate that devscripts pulls that crap in [00:28] or sudo apt-get --no-install-recommends install devscripts [00:29] hmm okay.. [00:29] so I made a package, but I can't install it because it says I already have the package installed. [00:29] But I purged it before [00:29] After it fails I can purge it again. [00:34] Ah there we go [00:34] sudo apt-get purge foo fails to remove it? sudo dpkg -i foo.deb fails to install it? can you share the source package? I'd be more than happy to take a look at it and see whats going on and help clean it up some [00:35] It didn't remove the /var/lib/dkms/vmwgfx/1.4.1 directory because it forgot about the dsc directory in there [00:37] ah I probably need to add a dh_installudev to debian/rules as well? [00:38] Depending on what sort of rules file dkms generates, yes. [00:38] not one containing dh_installudev :) [00:39] If it uses the “dh” tool then you wouldn't need it, but it's probably not that new :) [00:49] RAOF: where would the dh_installudev go in /etc/dkms/template-dkms-mkdsc/debian/rules? just before dh_link in binari-indep? [00:50] I'd put it next to the dh_install call, which I presume is in there somewhere. [00:54] I only see dh_installdeb and dh_installdirs [01:00] /lib/udev/rules.d/40-vmwgfx-dkms.rules [01:01] \o/ [01:01] Woot! [01:01] I added dh_installudev under the install target in rules [01:02] Yeah, that'd fly :) [01:04] do how do you guys manage packages like this? [01:05] do you do a git-init in the package dir and just "git add debian && git commit" and thats it? [01:05] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html [01:05] Generally something like that. [01:08] errr [01:09] That's the full toolchain thingy. git add debian && git commit is what often happens on a day to day level :) [01:19] ok [01:25] if you git init in debian/ you need to pass -i -I to debuild when you build packages so the .git crap doesn't end up in the package [01:25] or just add DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I" to ~/.devscripts [01:26] (sorry popped out there, glad it worked!) [01:27] there's no right way to do it, just whatever you prefer [01:27] causes lots of headaches adopting other peoples workflows to update packages, thats for sure :) [01:29] I'm just glad I have a package that I can use [01:31] So where do specify the package version? [01:31] debian/rules? [01:32] debian/changelog [01:32] The version of the most recent changelog entry is the version of the package. [01:33] ah [01:33] (dch is a useful tool for manipulating the changelog; I use emacs' debian-changelog mode for my stuff, though) [01:34] hmm okay [01:34] dch uses envar EDITOR? [01:34] Yes. [01:34] Yes it does [01:34] yeah dch -i to make a new changelog entry and automatically bump the package version (although it almost always does it wrong) [01:45] hehe so I noticed [01:53] Prf_Jakob: there's probably a 50 page document somewhere on the debian policy regarding the version string, but basically x.y.z is the upstream version, the part after - is the debian revision of the package, and if that debian version is modified in ubuntu it gets a ubuntuX version added [01:53] And if its vmw? [01:53] VMware* [01:53] do I add vmwX? [01:53] I just went with rX [01:53] for some reason [01:54] Sarvatt: It's actually not very complicated :P http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version [01:55] RAOF: that totally omits things like x.y.z-2 being higher than x.y.z-2~vmw1 though, hmm [01:55] oh no it doesnt [01:55] Prf_Jakob: If you're not expecting to distribute it, or if it's not going to conflict with a package name in the Ubuntu archives then the only real constraint on versioning is that you want it to be strictly monotone increasing, and the tools will raise warnings if you have a native package (one without a -$SOMETHING component). [01:56] RAOF: down the line I would like to make a ppa for it, now its just a internall thing. [01:56] Sarvatt: It doesn't say it in so many words, but it *does* say that “~” sorts before everything, including the empty string. [01:57] Prf_Jakob: Then you can go nuts with whatever versioning scheme you want :) [06:02] Sarvatt: and having 'DEBCHANGE_RELEASE_HEURISTIC="changelog"' in .devscripts makes dch a bit better when handling dvcs repos [06:03] no need to use -i [08:03] RAOF: do you know if *DM has been updated to the new '-background none' so patch 209 could be dropped from the server? [08:04] tjaalton: No, they haven't. [08:04] is there a bug about it? [08:05] I'm not sure. [08:05] ok [08:05] Looking. [08:06] i'm bisecting our patches to see which one causes wacom button clicks to move the cursor around [08:06] not happening on upstream code [08:06] so I came across that one [08:07] sure it doesn't cause it :) [08:08] at least gdm hasn't changed [08:08] :) [08:08] ubuntu_plymouth.patch still uses -nr [08:17] tjaalton: Now filed as bug #806857 [08:17] Launchpad bug 806857 in lightdm (Ubuntu) (and 1 other project) "Plymouth integration should use upstream “-background none” option (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/806857 [08:19] RAOF: thanks [08:19] I think kdm is not using -nr anymore [08:19] ScottK: can you verify ^ [08:21] the changelog of kdebase-workspace is confusing, it's talking about 07_kdmrc_defaults_kubuntu.diff, but there is no such patch but kdmrc_defaults.diff which is commented out :) [08:23] and I guess lightdm hasn't used -nr [09:42] ok, disabling patches 200-> fixed the cursor jumping, but only a fraction of the tablet surface was usable. bisecting some more [09:54] yep, it's the multitouch patches that cause the cursor jumping [10:22] Hurray! :/ [10:23] mikey_: So, what's broken? :) [10:25] Well, I was hoping to sort out a strategy to do a second session in X that plays nice with ubuntu, at the moment it's a bit of a hack based on my outsider readings on X. [10:26] mikey_: As in: run a second X server? [10:27] And then the game in that second server? [10:27] So basically all I do is utilise xinit to start a second X session along side the first and open openbox (I just chose this as something lightweight that didn't use Compiz) [10:28] And then it waits and opens a game on that [10:28] It's pretty simple but avoids a lot of the problems you get with compiz [10:29] There (just acording to poles of people using this strategy) is a slight performance boost over running it in one session [10:30] Also the game is slightly sandboxed so any major crashes don't effect the first x session [10:30] Right. [10:30] The problem is that it has become increasingly opaque in ubuntu how to deal with the security and x session management features. [10:31] So at the moment a commmand I use looks something like this: [10:32] xinit '/tmp/tmp-xinitrc' -- :1 [10:33] Where the tmp-xinitrc has a session command like: [10:33] exec ck-launch-session openbox-session [10:34] Ah, right, yes. ConsoleKit. [10:35] I had to introduce that to deal with sound problems. [10:35] Now there's issues about whether a user level application can start a session at all [10:35] i wouldn't expect xinit from an existing X session to work, as a regular user? [10:36] I can get arround it by getting people to turn on user level x session management but I don't know if that is a security risk [10:36] I presumed there's an implicit sudo in there :) [10:36] No [10:36] Sorry I was typing as you were. Hope that explains where I am [10:37] I think ck-launch-session is going to stop working properly, isn't it? consolekit is starting to require the sessions be set up with all the trimmings - vt, display number, etc. [10:37] Also there's a problem that when I exit openbox now something takes down the first x session as well [10:38] What is “user level x session management” in this context? [10:39] Sorry, you can tell X that users can start and stop sessions without sudo [10:43] I'm just looking for the change now, as I can rememebr exactly which file you cange [10:44] Right. /usr/bin/X is setuid, and from memory the wrapper has some authorisation hooks. [10:48] sudo dpkg-reconfigure x11-common [10:48] and choose "anyone" to enable X privileges [10:48] mikey_: I'm not entirely sure what you're looking to achieve. We're not deliberately breaking this sort of thing, but its also not something that we (or many upstreams) particularly think of either. [10:50] I was hoping to knock out a strategy that was more in keeping with the way that these things were intended to work. Since there is an issue with gaming on ubuntu. [10:50] The way that this *should* be fixed is by fixing whatever's wrong with compiz, basically. [10:51] I've asked the compiz people a couple of years ago if they intended to make some workaround for games but nothing has been forthcoming. [10:52] What is the actual problem? [10:52] They said they were. [10:53] Many games, particularly using Wine. Crash when run under Compiz or don't work at all [10:55] Can you give some examples? I've not run into any of these problems, but I haven't got a particularly extensive gaming library. [10:56] Well, I've not tried many games under compiz for a while as I've been using my approach [10:57] But I just started up the first game that came to mind Oblivion using wine [10:57] and while it ran the fullscreen did not cover the unity pannel [10:59] Ah, fullscreen. [10:59] The state that X forgot. [11:01] So, *that* is just a window management bug in compiz. [11:02] And sometimes the way to have things fixed is to fix them. There's not a huge difference in difficulty between fiddling around with running extra X sessions and fixing bugs in compiz. [11:02] Same issue on other wine games (just checked) so a wine compiz issue. [11:03] In the past there've been issues where wine games were in fact transparent. [11:04] And that was almost certainly a wine bug :) [11:04] No compiz [11:04] Well... compiz and maybe wine was misslabeling [11:05] Probably would have happened with another compositor too; wine was probably filling its windows with a transparent colour and not noticing because that only takes effect under a compositor. [11:06] I think actually it was thinking the window was a menu [11:06] as I had transparent menus at the time [11:06] Possible, if you set up compiz to make menus transparent. [11:08] But like I say, things may have change a lot over the last couple of years since I used wine games under compiz but increased crashes also were an issue. [11:09] The second session made that kind of problem no problem at all. [11:10] Yeah, but it's not a particularly wonderful solution. Specifically, it's not something that we'll do by default. [11:10] OK. [11:12] Can you give me any pointers to coping with session management if I continue to try to run an app that does this? [11:13] So would you recommend not enabling user level session management on security grounds? [11:13] No, not particularly. [11:14] Do you know what it is that is killing the first x session when I exit the second? [11:14] I guess GDM [11:14] I wouldn't think so, but it's possible I guess. [11:14] You're not starting an X server that gdm knows about. [11:15] It *might* be consolekit playing around on you. [11:16] How is a session started properly under Ubuntu at the moment? (Or where can I read about it?) [11:16] As I said, I think you're going to need to use something more clever than ck-launch-session soon [11:17] mikey_: X servers are started by the display manager, as are login sessions; check the lightdm source for details, pretty much. [11:18] Can I interact with the display manager to request a new session or do I need to reimplement what it's doing? [11:19] You possibly could? It'd be moderately involved, I think. [11:22] OK. Thank you for your help [12:34] RAOF: doh, thats a nasty mesa bug to have on the alpha 2 image [13:00] tjaalton: I can't find any evidence of a plymouth related -nr and I do see a background being set in kubuntu_63_ksplash_fix.diff, but I'm not sure if that's the same background setting or not. [13:00] So I think it's OK, but not sure. [13:01] ScottK: yeah, good === JanC_ is now known as JanC [17:47] Sarvatt: does sna in xorg-edgers somehow cause dri2 to stop working? [19:06] Sarvatt, hello [19:07] is it normal that the nvidia blob get broken a lot these days? or is my system messed up? rebuild the blob package solved the problem lately [19:10] hyperair: nope shouldn't be related, if anything I might have messed up one of the packages for natty? can ya pastebin your Xorg.0.log? [19:11] Sarvatt: Xorg.0.log shows dri2 present. [19:11] ricotz: oneiric nvidia in the archive? I have no clue, still have yet to try it after the multiarch stuff but i've got an alpha 2 image downloading now [19:11] Sarvatt: glxgears on the other hand... seems to not get redirected. [19:11] Sarvatt: so when i move the glxgears window around, it gets left behind just like pre-dri2 times [19:11] and when i activate some compiz animation it gets left behind as well [19:12] hyperair: LIBGL_DEBUG=verbose glxinfo output please [19:12] hyperair: hrm that got fixed recently [19:12] eh? [19:12] http://paste.debian.net/122245/ [19:12] also, wine seems to have artifacts with snb things. [19:12] the glxgears sticking around until you stop moving the window got fixed recently [19:12] i see [19:12] hyperair: amd64 right [19:12] yeah [19:13] hyperair: you need to install the 32 bit mesa libs for it to work [19:13] hmm [19:13] does mesa support multiarch yet? [19:13] in xorg-edgers? [19:13] edgers and oneiric yeah [19:13] oo nice. [19:13] natty and oneiric in edgers [19:13] ricotz, yes, the oneiric package, the glx module cant be loaded [19:13] Sarvatt, ° [19:13] ^ [19:13] oops [19:13] Sarvatt: do i need to get rid of ia32-libs? [19:13] hyperair: nope it shouldn't even look for things where that gets installed anymore [19:14] okay. [19:14] hyperair: add uhh [19:14] foreign-architecture i386 to /etc/dpkg/dpkg.conf [19:14] something foreign.. [19:14] aha [19:14] okay [19:14] and apt? [19:14] then sudo apt-get update and sudo apt-get install libgl1-mesa-dri:i386 [19:15] hopefully it'll pull everything it needs in [19:15] okay [19:15] let's see.. [19:15] aptitude update doesn't seem to be pulling in i386 things [19:15] i think some apt option is also needed. [19:16] Sarvatt: err, why is that needed for glxgears/compiz? [19:16] ricotz: to be honest i haven't even looked at multiarch on the blobs yet and am not sure whats going on, got an image downloading to install on my nvidia box right now [19:16] it isn't, was for wine [19:16] ah. [19:16] Sarvatt: Apt::Architectures [19:16] i knew i was missing something :) [19:17] he's using software rendering and getting artifacts, but i'm sure he wants to be using hardware acceleration so needs the 32 bit stuff :P [19:17] ack [19:17] Sarvatt, ok :) [19:17] glxinfo looks fine there hyperair, the glxgears problem you mentioned was fixed last week sometime though, have you not restarted X in a week? [19:18] Sarvatt: nah, my laptop just locked up and i've restarted [19:18] stupid mode switching [19:18] hyperair: ugh you said natty right? [19:18] yea natty [19:18] hyperair: hopefully it wasn't a compiz update in oneiric that fixed it then.. [19:18] ._. [19:18] hmmmmmmmmmmmmmmmm [19:19] lemme poke smspillaz. [19:19] oh wait he's in the same timezone as me. probably asleepn ow [19:20] i dont know what fixed it, mentioned it to ickle and went off to dublin and it was fixed sometime last week in the updates [19:22] hmm [19:22] i see. [19:23] err maybe it was http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=b460b9645451af84136c5daebbc00c7545de67f4 [19:23] whats your x-x-v-intel version [19:25] 2:2.15.0+git20110706.0be47f45-0ubuntu0sarvatt here [19:31] i'd put money on it being an old xserver-xorg-video-intel, that problem started with http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c3b1a0d7046a83b6daec03e5a562116e3adf3c71 === yofel_ is now known as yofel [19:43] *** 2:2.15.0+git20110706.0be47f45-0ubuntu0sarvatt~natty 0 [19:43] Sarvatt: ^^ [19:54] Sarvatt: urgh, multiarch on natty seems pretty broken. [20:00] hyperair: I feared as much :( you're the first person i've spoken to that's tried it, guess i'll be dropping multiarch and forking the packaging for crap to keep natty up to date in the end.. [20:01] heh [20:15] ricotz: so what are you doing when it dies? you said it happened when you upgraded stuff? [20:15] looks like its working ok here [20:22] ricotz: nevermind reproduced it, filing a bug [20:25] Sarvatt, what is the problem? [20:34] ricotz, howcome not many gnome3 updates for natty recently? [20:36] ricotz: not sure yet, this is a mess [20:36] http://bugs.launchpad.net/bugs/807209 [20:36] Launchpad bug 807209 in nvidia-graphics-drivers (Ubuntu) "Lost glx after first upgrade from oneirc alpha 2 install (affects: 1) (heat: 6)" [Undecided,New] [20:39] Sarvatt, alright, i will follow it, i suspected binutils (pulled from thin air ;)) [20:40] bjsnider, hmm, it isnt planned to update it to 3.1.x -- it would need a whole lot of unstable updates [20:40] Setting up libgl1-mesa-glx (7.11~1-0ubuntu3) ... [20:40] update-alternatives: renaming x86_64-linux-gnu_xorg_extra_modules slave link from /usr/lib/xorg/extra-modules to /usr/lib/x86_64-linux-gnu/xorg/extra-modules. [20:40] hrm [20:40] xserver is still trying to load from /usr/lib/xorg/extra-modules first [20:41] bjsnider, and might break a lot other things after G_CONST_RETURN and new gtk+3 deprecations [20:42] Sarvatt, hmm, it could have happen on mesa updates [20:42] brb [20:42] yeah that makes sense [20:42] [ 8.172] (==) ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules" [20:45] whats up with apport being useless btw [20:45] bryceh: ? [20:45] Sarvatt, ? [20:46] didn't attach anything to that bug i just filed [20:46] https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/807209 [20:46] Launchpad bug 807209 in nvidia-graphics-drivers (Ubuntu) "Lost glx after first upgrade from oneirc alpha 2 install (affects: 1) (heat: 6)" [High,New] [20:46] ah, nvidia [20:46] Sarvatt, so then if you reinstall nvidia-current the problem should be fixed, if it's only broken alternatives [20:47] Sarvatt, were there any error messages printed to console? [20:47] darn i've already rebooted since then but i dont believe so [20:47] Sarvatt, do you have xdiagnose installed? [20:48] it was a clean install, not sure, let me hook it back up [20:48] Sarvatt, try filing a bug against xorg or xserver-xorg-video-intel and see if that works properly [20:48] Sarvatt, aside from the move from xorg to xdiagnose I haven't uploaded any changes to the apport hooks [20:49] they've been working ok in my tests but some of the changes could easily break things in specific cases (i.d. proprietary drivers) [20:51] bryceh: yep no xdiagnose on an alpha 2 install [20:52] ok, so that's probably what the problem is [20:52] maybe xorg needs to depend on xdiagnose more forcefully? [20:53] tjaalton, ^^? [20:54] xserver-xorg should depend on it no? [20:54] oh xorg instead [20:55] thats what ubuntu-desktop depends on, and that pulls in x11-common, which has a recommends for xdiagnose that isn't getting pulled in [20:55] yeah [20:56] why would it not pull in an x11-common recommend? [20:56] only pulls in recommends of things it depends on directly maybe? [20:57] maybe slangasek would know [21:01] Sarvatt, anyway, meanwhile, can you manually install xdiagnose and confirm then that bugs are reported correctly? [21:01] bryceh: xorg depends on xfonts-scalable and that isn't pulled in either so i guess it should just be moved to depends [21:01] sure one sec i'll file a new one [21:01] I'm going to upload a new xdiagnose 0.7 probably early next week, with some semi-substantial changes [21:04] bryceh: yep it works, updated that bug [21:04] btw its in universe still [21:04] ?? [21:05] it downloaded xdiagnose from universe [21:05] maybe that's why it didn't get pulled in? [21:05] .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0' [21:05] https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/807209 apport info on that [21:05] Launchpad bug 807209 in nvidia-graphics-drivers (Ubuntu) "Lost glx after first upgrade from oneirc alpha 2 install (affects: 1) (heat: 8)" [High,New] [21:06] cursor theme in use? that might be a bit too much info :) [21:07] Jun 18 00:04:26 tjaalton, btw on upgrading to latest I notice xorg didn't pull in xdiagnose; does it need stro\ [21:07] nger than Recommends? [21:07] Jun 18 00:05:36 bryce: it is, and it got installed here though [21:07] Jun 18 00:05:44 hmm [21:07] Jun 18 00:05:53 recommends should be enough [21:07] Jun 18 00:06:35 if your apt is configured to install recommended packages (which is on by default sinc\ [21:07] e a couple of years) [21:07] maybe the installer uses different defaults [21:08] Jun 18 00:07:09 total defaults on this system, fresh install as of 2 days ago [21:08] Jun 18 00:07:15 ok [21:08] Jun 18 00:07:29 I'll check my logs [21:08] Jun 18 00:08:15 ah I had it installed already [21:09] but we didn't look into it beyond that :-/ [21:19] bryceh: cool beans, just sucks we're going to get a bunch of alpha 2 bugs with no apport info :P [21:19] maybe [21:21] this might explain why we've got relatively few gpu hang bugs on -intel [21:22] for sure [21:23] not a big deal; we'll get plenty more soon [21:24] bryceh, RAOF: every time I try lightdm it fails to work for me [21:24] mouse and kb don't work [21:25] I found out today that the X server doesn't have any input devices [21:25] it does under gdm though [21:25] cnd: i had to pin udev to the natty version on one of my machines to get around that.. :( [21:25] cnd, hmm worked for me when I poked at it last week [21:25] Sarvatt, interesting... [21:25] Sarvatt, I'll try that out [21:26] cnd: got an ssd in that machine? [21:26] Sarvatt, no [21:26] there have been some bug reports about with lightdm, it'll make X SIGQUIT when you first hit a '2' or enter [21:26] ok that was my running guess, booting too fast since it doesn't happen on a second identical e6420 minus the SSD [21:28] i should have swapped the drives before giving it to RAOF to see if it had the same problem [21:30] Sarvatt, natty udev doesn't help... [21:31] $ sudo udevadm trigger [21:31] that makes it work [21:31] well, it made mouse work [21:31] err yeah, no keyboard or anything before lightdm starts and can't interact with the system at all, thats different from when lightdm didn't give me devices [21:31] kb doesn't... [21:32] sorry, got the symptoms confused, i had the lightdm problem a long time ago and it fixed itself about 3 weeks ago [21:32] my kb doesn't come up, perhaps because there's no udev event for it? [21:37] so now gdm won't come up [21:37] and lightdm is still broken... [21:37] anything in /var/log/gdm /var/log/lightdm of relevance? [21:38] which log file should I look in in /var/log/gdm? [21:38] like :0.log [21:38] dont suppose there's anything useful in /var/log/lightdm/lightdm.log? [21:38] err guess i should read scrollback before asking lol [21:38] also, sorry if you already mentioned it but does keyboard work on vt console? [21:39] he probably cant even switch to a vt to check [21:39] oh true [21:39] i couldn't when i had that problem [21:39] I'm ssh'd in, so I can chvt [21:39] cnd, umm... ok so presumably you can get into grub on boot? can you boot into a recovery session and just verify kernel input is working outside X? [21:40] I can type into a vt [21:40] ok [21:40] I know kernel input works [21:40] or at least it did until I dist-upgraded today [21:40] and I've had the lightdm issue for quite some time [21:40] ah ok, guess I missed that [21:41] maybe I should back up and ask, what have you narrowed the problem down to? [21:41] cnd: does it work if like, you boot with text instead of splash into recovery and continue past that to skip all the plymouth stuff? [21:41] hmmm, RAOF did stuff to this machine at the sprint [21:41] said he took off fglrx [21:41] but something seems odd [21:42] well, I thought maybe he didn't remove the fglrx lines from Xorg.conf, but I think I'm just seeing a standard error about not finding fglrx [21:42] "did stuff" - do you mean, with the objective of fixing input? or that the input breakage started after that? [21:42] yeah that's innocuous [21:42] no, with the objective of fixing 3d so unity would run :) [21:42] if fglrx is removed you shouldn't need xorg.conf [21:43] hmm, from dmesg: [21:43] [ 395.259525] gdm-simple-slav[1310]: segfault at 0 ip 00007f89d2fc9f15 sp 00007fff4ec516f0 error 4 in libnss_compat-2.13.so[7f89d2fc6000+8000] [21:43] I wouldn't think that would affect input [21:44] yeah, I think that's the cause of gdm not working [21:44] well, I have two issues now [21:44] input doesn't work in lightdm [21:44] and gdm doesn't work at all [21:44]