[00:46] jcristau: all the nvidia drivers in sid except 96.xx work with it, but yeah fglrx is at least a month behind [00:47] not sure how the blobs work in debian though, in ubuntu someone has to add the new abi and reupload them but the drivers actually do work [06:53] Sarvatt: all drivers in sid look like they already have xorg-video-abi-15 in their list of alternative dependencies (except 96xx) [06:53] but 96xx already doesn't support 1.14 [06:54] s/all/& nvidia/ [16:40] Prf_Jakob: is there a plan for a vmware ddx release some time soon? [16:40] jcristau: there is a plan yes [16:40] jcristau: just need QE to sign off. [16:40] ok, thanks [17:23] Hi, is vesafb.ko missing in Trusty? Should udev-fallback-graphics get updated to `modprobe uvesa`? [17:23] $ grep vesa /etc/init/udev-fallback-graphics.conf [17:23] modprobe -q -b vesafb [17:23] $ ls /lib/modules/*/kernel/drivers/video/*vesa* [17:23] /lib/modules/3.13.0-5-generic/kernel/drivers/video/uvesafb.ko [17:43] Ah, and v86d is not installed either... from its description and the output of `dmesg`, I'm guessing it's needed... [17:55] Anyway, I think that the fallback graphics logic has been broken since 12.04 [17:56] uvesa is not meant to be used [18:03] In the 10.04 days, when the "appropriate driver" failed to initialize xorg, a switch to xvesa happened, and a dialog was displayed about starting a session with fallback graphics etc [18:03] This doesn't work in 12.04, 14.04 etc, xorg just restarts continuously... [18:14] it never used vesafb [18:15] indeed [18:17] Then I don't know what that "udev-fallback-graphics.conf" does, but the symptoms that I see are still there, i.e. no fallback graphics probably since we started using KMS. [18:18] And someone should remove that udev-fallback-graphics service since vesafb isn't being shipped, it's just producing annoying messages in syslog... [18:22] on what hw?? [18:22] -? [18:23] if kms is used but it doesn't work, there's no way to fallback to anything aiui [18:43] Aaah ok that might be the reason then [18:44] I've had reports from many schools here, I don't remember the graphics cards but I can note them down when needed, I think I remember some older sis ones... [18:48] they don't have kms [18:50] Then maybe there's no fallback graphics logic anymore :) [18:50] sure is [18:50] if the xserver crashes [18:50] it'll get loaded with a fallback conf [18:51] Hmm maybe we somehow accidentaly block that in LTSP, I haven't seen it since 10.04 [18:52] i mean if the xserver crashes when starting with default (no) conf [18:52] In LTSP by default we don't use a xorg.conf. But we don't use lightdm etc either, we have our own DM called ldm, and X is launched by that [18:53] We have about 500 schools here, I haven't seen the fallback graphics triggered in years... [18:53] Do you happen to remember offhand what upstart job starts the fallback graphics? [18:53] Or is that xorg? [18:55] failsafe-x.conf [18:56] Thank you, reading... [18:57] i'd say it's a good thing you never saw it.. [18:58] I did see black screens that we had to work around with XSERVER=vesa though :) [18:58] Lots of them [18:58] crappy sis driver then [18:58] it can't detect if you get no output [18:58] It's not only sis... we have a lot of old cards, a lot of xorg crashes etc [18:58] or crappy drivers in general [18:59] The bad thing is that they worked fine up until 10.04, and they started having serious issues since 12.04 [18:59] And they're very very slow in gtk too *now*, maybe because of the switch to cairo instead of gdk... [18:59] Like, needing 0.5 sec to draw one menu item in gnome-panel... [19:00] no exa support then [19:00] 10 times slower than 10.04, at least [19:00] which 12.04? [19:00] I've seen that with sis and older nvidia cards (pre-geforce), I haven't yet pinpointed it exactly [19:00] We use gnome-fallback with metacity [19:01] .{1,2,3} [19:01] 3 [19:01] QAh [19:01] Ah [19:01] I've tried with 3.2 kernel and xorg, and with the raring one [19:01] .3 has the raring stack [19:01] sis crashes xorg with the saucy one [19:01] and kernel [19:01] *raring [19:02] But the issue was there in both of the kernels/xorg combinations... [19:02] so it was already 1.13 that dropped exa [19:02] err [19:02] not exa [19:02] the other one [19:02] uxa? [19:02] no [19:02] OK I got what you mean, I also don't remember it :) [19:03] I tried gtkperf and I saw very big variations in some of its tests [19:03] Like, two PCs having similar times everywhere, but in 2 tests, the first pc would need 50 seconds and the other one 5 seconds... [19:03] *xaa [19:04] yup [19:04] And I thought it was because of some functions using software instead of hw acceleration, in some drivers... [19:05] (and those software implementations being very bad... :-/) [19:07] probably that too [19:07] in other parts [19:08] Would it be possible to run a very old xorg in a recent ubuntu? [19:09] E.g. 1.7.6 from Lucid, to Trusty? [19:13] start on stopped lightdm EXIT_STATUS=[!0] or stopped gdm EXIT_STATUS=[!0] [19:13] ...that's why it never gets triggered in LTSP, since we're using LDM... [19:14] I'll check if we can emit a "stopped lightdm" signal even if we don't have lightdm installed... [19:14] hehe [19:14] it might be possible to forward-port, yes [19:15] and rebuild the drivers [19:20] brb, my i915 hangs every now and then in trusty... :-/ [19:21] that's progres.. [19:21] +s [22:46] Sarvatt, done any displayport troubleshooting recently? does this Xorg.0.log jog any ideas? [22:46] http://paste.ubuntu.com/6840625/ [22:47] user has a usb-to-hdmi adapter to run an external monitor [22:47] adapter is http://www.amazon.com/Sabrent-1920x1080-1600x1200-DisplayLink-USB-HDMI/dp/B005UKG4KU/ref=cm_cr_pr_product_top [22:47] er s/displayport/displaylink/ [22:48] it seems the kernel driver is not exposing the EDID from the monitor [22:49] dmesg & xrandr: http://paste.ubuntu.com/6840629/ http://paste.ubuntu.com/6840630/ [22:49] the monitor lights up with VESA modes okay [22:50] we tried guessing a modeline to force it to 1920x1080, and it seems to work, but screen stays black [22:50] DVI-1-0 connected 1920x1080+1920+0 (0xfa) normal (normal left inverted right x axis y axis) 0mm x 0mm [22:50] Identifier: 0xf3 [22:50] Timestamp: 1331890 [22:50] Subpixel: unknown [22:50] Gamma: 1.0:1.0:1.0 [22:50] Brightness: 1.0 [22:50] Clones: [22:50] CRTC: 4 [22:50] CRTCs: 4 [22:51] Transform: 1.000000 0.000000 0.000000 [22:51] I also had him try connecting to other CRTCs but he just gets errors for anything other than 4 [23:04] bryceh_: Can you get the kernel to fake a 1920x1080 EDID for it? [23:05] That would be something like drm_kms_helper.edid_firmware=DVI-1-0:edid/1920x1080.bin [23:08] RAOF, I can give that a try, but shouldn't a forced modeline work around that? [23:09] I'm going to have him connect the monitor to a known good setup to collect the correct edid and modeline [23:09] bryceh_: Depends; My LCD display with broken EDID hardware doesn't get detected as *connected* unless I force an edid. [23:09] So a modeline doesn't help for my display, but faking an edid does. [23:09] hmm, ok [23:10] one other weird thing is that he assures me this setup had been working up until recently, without need for modeline forcing