| achiang | is there something else i need to do while testing X clients inside a chroot? i've exported my DISPLAY=localhost:0.0, and issued an xhost + in the host as well | 02:29 |
|---|---|---|
| achiang | ah, my X server is launched with -nolisten tcp | 02:30 |
| RAOF | Right. | 02:31 |
| RAOF | Because it is, by and large, a bad idea. | 02:31 |
| achiang | RAOF: agreed but... i'm a developer? :) | 02:31 |
| RAOF | You could bind-mount /tmp into your chroot (or just /tmp/.X0.whatever) | 02:31 |
| achiang | RAOF: hm, and that means i don't have to restart my X server? | 02:33 |
| RAOF | Indeed. | 02:33 |
| achiang | thanks | 02:33 |
| RAOF | That should allow apps in the chroot to access the local transport. | 02:33 |
| achiang | ok, i'll try that | 02:34 |
| achiang | RAOF: hm, i don't think that actually worked for me | 02:40 |
| RAOF | Ah. Sorry, it's been a while since I actually tried to run an X client in a chroot. | 02:40 |
| achiang | http://pastebin.ubuntu.com/503617/ | 02:42 |
| RAOF | How about just DISPLAY=:0? | 02:43 |
| achiang | ah ha! | 02:44 |
| achiang | thank you | 02:44 |
| RAOF | localhost:0.0 says ‘let's go over TCP’ :) | 02:44 |
| achiang | indeed, you're right. | 02:45 |
| achiang | dinnertime | 02:47 |
| jcristau | RAOF: bind-mounting /tmp shouldn't even be needed these days, since Xlib (well, libxcb) will try the abstract domain socket first | 08:55 |
| RAOF | Oh, funkyi. | 08:56 |
| RAOF | And now I know :) | 08:57 |
| === thade_w is now known as Alexia_Death_ | ||
| vish | Sarvatt: nope, 2.6.35-23-generic #34~pre201009220900-Ubuntu , doesnt solve it either.. :( | 12:06 |
| * vish tries with matching mainline.. | 12:06 | |
| kamstrup | is there any way I can get the i945 driver to output some debugging info somewhere? | 13:40 |
| kamstrup | i am debugging what seems to be a leak in Unity which may or may not be driver related | 13:41 |
| tseliot | kamstrup: "echo 4 | sudo tee /sys/module/drm/parameters/debug" or, if you want an extremely verbose output in dmesg use "1" | 13:49 |
| kamstrup | tseliot: awesome, thanks! | 13:49 |
| Sarvatt | tseliot: http://www.nvnews.net/vbulletin/showthread.php?p=2326225 \o/ | 15:57 |
| Sarvatt | "@luk1don: I haven't forgotten about 96.43.*, I just haven't had much time to work on it lately. I'm hoping to get started on xserver 1.8 support soon, and xserver 1.9 support shortly thereafter." | 16:01 |
| tseliot | Sarvatt: yes, we're discussing that over the phone | 16:14 |
| === You're now known as ubuntulog | ||
| seb128 | tormod, federico1: hey | 20:28 |
| tormod | seb128, hi | 20:29 |
| seb128 | federico1, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=67958ef6faab5797d5c5ad939db36f393706984a | 20:29 |
| seb128 | tormod wonders why that was required rather than letting xorg handle screen configs | 20:29 |
| seb128 | it seems some drivers are buggy and don't like xrandr calls | 20:30 |
| tormod | that is not the problem I think | 20:30 |
| seb128 | why do you think it's not the problem? | 20:30 |
| tormod | rather that g-s-d picks modes poorly | 20:30 |
| seb128 | hum, at least one of the bugs you replied to had correct modes | 20:31 |
| seb128 | but the radeon drivers just seems buggy | 20:31 |
| seb128 | tormod, well you are not coherent | 20:31 |
| tormod | in bug 643118 xorg chooses the "preferred" mode but xrandr picks another one | 20:32 |
| seb128 | in your email you wrote | 20:32 |
| ubot4 | Launchpad bug 643118 in gnome-settings-daemon (Ubuntu) "[RV350] Desktop corruption – Screen only shows vertical bands (dup-of: 640807)" [Undecided,Confirmed] https://launchpad.net/bugs/643118 | 20:32 |
| ubot4 | Launchpad bug 640807 in gnome-settings-daemon (Ubuntu) "Forces low refresh rate on CRT monitor (affects: 6) (dups: 2) (heat: 38)" [Undecided,Confirmed] https://launchpad.net/bugs/640807 | 20:32 |
| seb128 | "So IMO g-s-d should just leave it as | 20:32 |
| seb128 | it is or read out correctly what xorg has set up." | 20:32 |
| tormod | that's not coherent? | 20:32 |
| federico1 | tormod: hey | 20:32 |
| tormod | hi federico1 | 20:32 |
| federico1 | tormod: I put in that patch to let OEMs tweak the RANDR configuration when the user first logs in | 20:33 |
| federico1 | so that they don't have to mess with xorg.conf, or patch g-s-d in strange ways | 20:33 |
| tormod | federico1, but there should be a don't-touch option :) | 20:33 |
| federico1 | tormod: what do you mean? | 20:33 |
| federico1 | ah | 20:33 |
| federico1 | like | 20:33 |
| seb128 | federico1, they argue that the default should be "let xorg be smart" | 20:33 |
| tormod | or alternatively, that patch is fine, but something else must be fixed | 20:34 |
| seb128 | because g-s-d is often buggy | 20:34 |
| federico1 | what is the exact problem? | 20:34 |
| seb128 | g-s-d seems to not know about xrandr preferred mode | 20:34 |
| federico1 | yes, it doesn't use that anymore | 20:35 |
| seb128 | federico1, well basically https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/640807 | 20:35 |
| ubot4 | Launchpad bug 640807 in gnome-settings-daemon (Ubuntu) "Forces low refresh rate on CRT monitor (affects: 6) (dups: 2) (heat: 38)" [Undecided,Confirmed] | 20:35 |
| seb128 | https://bugzilla.gnome.org/show_bug.cgi?id=572502 | 20:35 |
| * federico1 reads | 20:35 | |
| ubot4 | Gnome bug 572502 in libgnome-desktop "gnome-display-properties should pick the preferred xrandr mode" [Normal,Unconfirmed] | 20:35 |
| seb128 | I think is the same issue | 20:35 |
| tormod | so there are two independent logics and sometimes xorg's work better than g-s-d's, right? | 20:37 |
| seb128 | well I'm not sure to understand why g-s-d picks the wrong one | 20:38 |
| seb128 | but I would be of the advice to let xorg alone by default | 20:38 |
| seb128 | ie not do any change from g-s-d if there is no config on disk | 20:39 |
| seb128 | or we could try to fix g-s-d | 20:39 |
| federico1 | ugggh, too many variables | 20:39 |
| federico1 | they are using nvidia's drivers | 20:39 |
| tormod | there are also a lot to be fixed in xorg and drm :) | 20:39 |
| federico1 | and they are using a monitor with bogus EDID values | 20:39 |
| seb128 | federico1, I guess the first question is "why g-s-d needs to touch the video config after xorg by default" | 20:40 |
| seb128 | I understand that we want the option to apply a config | 20:40 |
| seb128 | or to force a mode with gconf keys | 20:40 |
| seb128 | but if we are not in those case it seems safer to just let xorg pick the config | 20:40 |
| tormod | sounds sane | 20:41 |
| federico1 | seb128: because we don't know what xorg will give us, so we'd rather go to a known-good mode | 20:41 |
| federico1 | hmmmmm | 20:41 |
| federico1 | seb128: maybe you'd like a boolean use_boot_time_configuration meta-key | 20:41 |
| federico1 | or something | 20:41 |
| tormod | doesn't xrandr tell you what xorg has set up? | 20:41 |
| seb128 | well why would you know better than xorg if there is no config on disk? | 20:41 |
| seb128 | you being g-s-d | 20:41 |
| tormod | let's have a role play here :) | 20:42 |
| federico1 | because I don't trust xorg's startup values | 20:42 |
| seb128 | if those are wrong shouldn't we fix xorg? | 20:42 |
| federico1 | fixing xorg takes too long ;) | 20:42 |
| federico1 | so | 20:42 |
| federico1 | I'll happily include a patch that makes the boot-time configuration conditional | 20:42 |
| federico1 | with some use_boot_time_configuration key or something reasonably-named | 20:43 |
| seb128 | ok | 20:43 |
| seb128 | I was not sure if we should add a key or change the current one to be an int | 20:43 |
| seb128 | like 0 = let xorg alone | 20:43 |
| seb128 | 1 = force external monitor on | 20:43 |
| seb128 | 2 = force those off | 20:43 |
| federico1 | well, we have two keys right now; it gets a bit hairy to think what would happen with the 3x3 combinations | 20:44 |
| tormod | are "we" upstream or ubuntu-specific? | 20:44 |
| seb128 | upstream | 20:44 |
| federico1 | upstream | 20:44 |
| seb128 | federico1, ok thanks, seems reasonable to me | 20:45 |
| seb128 | so add a key use_boot_time_configuration | 20:45 |
| federico1 | (it's not hard to think what *should* happen with the 9 combinations, but I'd rather spare the admin from having to think about that) | 20:45 |
| federico1 | seb128: yeah, that would be best, I think | 20:45 |
| seb128 | and then we can fix the g-s-d bugs which lead to pick wrong mode as well | 20:45 |
| federico1 | hmmm | 20:45 |
| federico1 | use_boot_time_configuration or use_xorg_configuration (the reverse)? | 20:45 |
| federico1 | I'd like it to be obvious from the key name that it's an either/or thing | 20:46 |
| seb128 | I'm not sure right now what you call boot time | 20:47 |
| seb128 | I think use_xorg_configuration is easier to understand | 20:47 |
| tormod | but does it "use" any xorg conf, or just refrains from reconfiguring? | 20:48 |
| seb128 | it's not meant to be xorg.conf | 20:48 |
| seb128 | but as I understand it if the key was set it would do what g-s-d was doing before | 20:49 |
| tormod | I did not mean "xorg.conf" | 20:49 |
| seb128 | ie letting the display config as xorg set it | 20:49 |
| seb128 | federico1, ^ right? | 20:49 |
| federico1 | yeah, correct | 20:51 |
| federico1 | i.e. by not touching the randr setup at all | 20:51 |
| tormod | so is it a question of "do-not-touch" or "do-initial-configuration" ? | 20:51 |
| federico1 | tormod: I'm leaning toward a do-not-touch kind of name now, with False by default - if you need to make it True, it means that you have a special case due to your X setup anyway | 20:52 |
| tormod | I think use_xorg_configuration implies that g-s-d configures stuff actively | 20:52 |
| jcristau | eww. | 20:53 |
| seb128 | let_xorg_configuration? ;-) | 20:53 |
| tormod | but how do we solve these cases when this new default False makes it impossible for people to boot the Desktop CD? | 20:53 |
| seb128 | by debugging why g-s-d apply a wrong config | 20:54 |
| tormod | is there any case where xorg is wrong and g-s-d is right? | 20:54 |
| tormod | I would have left do-not-touch default to True, and switch it if the user reconfigures his settings | 20:55 |
| jcristau | tormod++ | 20:55 |
| tormod | I think "special cases" is more widespread than you might think, ask any xorg developer | 20:56 |
| tormod | well, we'll see now that the RC is out :) | 20:57 |
| seb128 | seems fine to let xorg alone by default | 20:58 |
| seb128 | that's what I suggested in my email | 20:58 |
| seb128 | let xorg alone if no config is on disk or key set | 20:58 |
| bryceh | seb128, agreed | 20:58 |
| seb128 | tormod, I will let you reply to the bug or email | 20:59 |
| seb128 | I think that's a plan of action | 20:59 |
| seb128 | doing a patch to add this "let_xorg_config" | 20:59 |
| seb128 | which we can set to true by default | 20:59 |
| seb128 | upstream can decide to set to false if federico1 disagrees | 20:59 |
| seb128 | I need to run, I'm already late | 20:59 |
| bryceh | heya federico1 | 20:59 |
| seb128 | see you later | 20:59 |
| tormod | thanks seb128 | 20:59 |
| jcristau | sadly monitor resolution is not the only place gnome does that. :( | 21:00 |
| tormod | I am sure we can make federico1 agree :) | 21:00 |
| federico1 | hey mister bryceh | 21:01 |
| federico1 | tormod: well, xorg has fed us such shitty defaults in the past that I don't want to lose the client-side workarounds | 21:02 |
| federico1 | not that *anything* is well-documented, though... | 21:02 |
| jcristau | you don't know whether something is the default or what the user explicitly set up in xorg.conf | 21:03 |
| tormod | federico1, optional workarounds are fine, but trashing all the work that went into xorg logic would be stupid | 21:03 |
| jcristau | so if you don't have an explicit config imo you should leave things alone | 21:03 |
| bryceh | federico1, I've been thinking what we need is a big huge truth table of expected behaviors for different situations | 21:03 |
| jcristau | and it's not like fixing things up in the right place is hard | 21:04 |
| jcristau | xorg takes patches.. | 21:04 |
| bryceh | federico1, so for instance, if a user boots an unconfigured system with two identical external monitors, it should do dual head. but a lvds + projector would behave differently | 21:04 |
| federico1 | jcristau: I'm sure they do; the problem is getting the patches written :) | 21:04 |
| federico1 | like | 21:04 |
| jcristau | federico1: if you can write them for g-s-d you can put the same logic in X.. | 21:05 |
| federico1 | in RANDR 1.3 the spec was updated to say that all drivers should export a ConnectorType property | 21:05 |
| federico1 | but as of today, only radeonhd actually exposes that property | 21:05 |
| federico1 | I filed bugs for each driver independently - none are fixed yet | 21:05 |
| federico1 | bryceh: sounds interesting! | 21:06 |
| bryceh | federico1, I mean, regardless of where its implemented, the expectations are going to be consistent | 21:06 |
| federico1 | bryceh: hmm, do we have a way to actually detect projectors vs. monitors? | 21:06 |
| federico1 | maybe "if $output can only do 1024x768, it's probably a projector"? | 21:06 |
| bryceh | federico1, physical dimensions = 0mm x 0mm? ;-) | 21:07 |
| federico1 | could be | 21:07 |
| federico1 | bryceh: if you play with it, I'd be very happy to see that | 21:07 |
| federico1 | I wonder what projectors say for the vendor in EDID | 21:07 |
| bryceh | anyway, several times now I've seen where there has been an undocumented assumption about how two monitors should be automatically laid out, and it doesn't account for some corner case | 21:08 |
| bryceh | but having both xorg and gsd trying to be smart seems to result in weird results, maybe some toe stepping such as in this case, etc. | 21:08 |
| bryceh | federico1, another perhaps better example is whether LVDS should be blanked if there is an external monitor | 21:09 |
| bryceh | i.e., is that what we expect to happen when we connect an external monitor, or a bug? | 21:10 |
| federico1 | bryceh: yeah, that needs some connection with external policies... if you close your lid while an external monitor is connected, does that mean "I only want to use the external one" or "suspend the laptop and let me turn off the monitor by hand"? | 21:11 |
| federico1 | (plus, docking stations are a bucket of fail) | 21:11 |
| federico1 | someone needs to sit down and write down all the cases | 21:11 |
| bryceh | federico1, exactly... so many questions for all these different configs, and I don't know if it's documented anywhere what the *expected* behavior is for those. | 21:11 |
| federico1 | there *is* missing infrastructure for lids and docking stations; I was talking to mjg59 the other day about this | 21:11 |
| bryceh | regardless of where the configuration is actually done, having that written down would do a lot to help to ensure it gets implemented right, and would enable testers to be more effective at reporting discrepancies | 21:12 |
| federico1 | yeah | 21:12 |
| tormod | should I mark the bug in progress and/or assign it to someone? | 21:16 |
| federico1 | tormod: no idea; is seb128 writing the patch or something? | 21:17 |
| federico1 | bryceh: if you blog about this, I'll link it from my blog - it's important stuff and we need testers | 21:18 |
| federico1 | (or people with funky setups) | 21:18 |
| tormod | federico1, it sounded like he would do it, no? | 21:18 |
| federico1 | yeah, that's what I thought | 21:18 |
| tormod | I'll assign him so he does not forget ;) | 21:18 |
| tormod | d*mn I can't, where did my lp superpowers go :) | 21:19 |
| bryceh | oh yeah, assigning to others was disabled in launchpad. | 21:20 |
| bryceh | was too much abused | 21:20 |
| bryceh | tormod, but I should be able to do it, what was the bug #? | 21:20 |
| tormod | 640807 | 21:21 |
| bryceh | done | 21:21 |
| bryceh | I think you have to be a member of the team that is driver for the package or something | 21:22 |
| vish | Sarvatt: hi, that patch seems not need for the guest session flickering bug.. | 21:24 |
| vish | Bug 652934 | 21:24 |
| ubot4 | Launchpad bug 652934 in xserver-xorg-video-ati (Ubuntu) "[RV515] Guest session causes screen to flicker violently and session is unusable (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/652934 | 21:24 |
| vish | Sarvatt: i'm using the older mainline kernel » 2.6.35-02063504-generic #201008271919 and it seems to not give the issue | 21:25 |
| vish | will test for longer … :) | 21:25 |
| vish | needed* | 21:26 |
| === albert231 is now known as albert23 | ||
| === yofel_ is now known as yofel | ||
| Sarvatt | sheesh, the kubuntu plymouth splash blows the ubuntu one out of the water :) | 23:33 |
| Sarvatt | vish: ugh, so its broken on the ubuntu kernel but working on the mainline one? | 23:33 |
| vish | Sarvatt: yup | 23:35 |
| Sarvatt | and that was the case even back in .33? so it's something we've carried over breaking it.. | 23:35 |
| vish | yea, even with .33 mainline i never had problems | 23:36 |
| vish | Sarvatt: kubuntu plymouth is better?? | 23:37 |
| Sarvatt | no comparison, it looks so much better | 23:37 |
| * vish oh googles for videos! | 23:37 | |
| Sarvatt | background behind the logo is a nice gradient | 23:37 |
| vish | oh! no videos up yet ;p | 23:40 |
| Sarvatt | kay, trying to view it in a VT isn't a good idea :) | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!