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