| wgrant | bryce: What do you think of my proposed fixes for bug #207781? | 10:39 |
|---|---|---|
| ubottu | Launchpad bug 207781 in gnome-settings-daemon "gnome-control-center and gnome-settings-daemon hardcode "Synaptics Touchpad", which breaks without xorg.conf" [Low,Confirmed] https://launchpad.net/bugs/207781 | 10:39 |
| Q-FUNK | howdy! | 15:24 |
| Q-FUNK | is there any temporary freeze on syncs from Debian? | 15:25 |
| tjaalton | yes, until intrepid is released :) | 15:28 |
| tjaalton | has been in effect for some time now.. | 15:28 |
| Q-FUNK | hm | 15:28 |
| tjaalton | if you mean automatic syncs | 15:29 |
| Q-FUNK | the sync for -geode was approved a while back, but still hasn't happened | 15:29 |
| Q-FUNK | no, manual ones too | 15:29 |
| Q-FUNK | would need to be synced from experimental | 15:29 |
| tjaalton | we are in feature freeze, so new upstream versions need more paperwork | 15:30 |
| Q-FUNK | this is a bugfix release. same 2.10, but .1 | 15:30 |
| tjaalton | still | 15:30 |
| Q-FUNK | but again, the sync was approved before the feature freeze | 15:30 |
| tjaalton | ok, then it should be fine. still, no archive admins here | 15:31 |
| tjaalton | wgrant: oh, so you've hacked g-s-d support for synaptics properties+ | 15:41 |
| tjaalton | ? | 15:41 |
| Q-FUNK | ah, cjwatson just synced it :) | 15:44 |
| tseliot | federico1: I'm trying to apply some settings (loaded from my own xml file) as soon as I launch the Screen capplet (without having to click on the Apply button). Wouldn't it be enough to set the members of app->current_configuration and call XSendEvent ? | 18:25 |
| tseliot | currently the screen flashes but my settings are not applied | 18:25 |
| federico1 | tseliot: hmmm, I think the event just tells gnome-settings-daemon to reread .config/monitors.xml and apply *that* configuration | 18:26 |
| federico1 | tseliot: i.e. the "apply" button re-saves that file, and then sends the event | 18:26 |
| tseliot | federico1: is there no way to force the setting daemon to use my xml file (with a different name)? | 18:27 |
| tseliot | federico1: ah, maybe I should save the settings to the official xml file | 18:27 |
| federico1 | tseliot: I'm not sure what you are trying to do, but yeah, having two files with different configurations sounds weird :) | 18:28 |
| tseliot | federico1: if the virtual resolution is checked and it's not set and the framebuffer is not enough | 18:29 |
| tseliot | the settings won't be saved to the xml file | 18:30 |
| tseliot | therefore I would like the program to save such settings to another xml file | 18:30 |
| tseliot | which can then be loaded on next login by launching gnome-display-properties --load-desired-settings | 18:31 |
| tseliot | this should make the program load the settings from the other xml file and apply them | 18:31 |
| federico1 | tseliot: oh, I see | 18:31 |
| federico1 | hmmmm | 18:31 |
| federico1 | but how would the user run g-d-p with that option? | 18:32 |
| tseliot | federico1: the first time the user tries to set up the multiple screens layout he will see a dialog which asks him whether he wants to have the virtual resolution set automatically in the xorg.conf. Then he is told to log out and log in again. | 18:34 |
| tseliot | a .desktop file will make sure that on next login the capplet is called with that parameter | 18:34 |
| tseliot | so that when he logs in the program will show app and apply the settings | 18:34 |
| tseliot | provided that the connected outputs are the same | 18:35 |
| tseliot | federico1: of course the .desktop file is added to the gnome-session | 18:36 |
| federico1 | hmmmmm | 18:44 |
| federico1 | tseliot: so you assume that the configuration *will* work once you reboot? | 18:44 |
| tseliot | federico1: no, therefore both the other xml and the .desktop file are removed as soon as the application starts with the parameter | 18:45 |
| tseliot | federico1: the only advantage would be that the user wouldn't have to set up the screens again after adding the virtual resolution and restarting X | 18:46 |
| tseliot | but it shouldn't break anything | 18:47 |
| federico1 | tseliot: sounds good. One thing that I'd like is, if you start g-d-p again before rebooting, then it should tell you that your settings don't match the current state because you haven't rebooted yet | 18:47 |
| federico1 | with a cute "!" icon or something :) | 18:47 |
| tseliot | federico1: yes, this is definitely a good idea and it was part of the plan ;) | 18:48 |
| federico1 | tseliot: cool | 18:49 |
| federico1 | tseliot: hmmm, to have less moving parts (the desktop file, etc.) could you simply do this: | 18:49 |
| federico1 | 1. user hits Apply | 18:49 |
| federico1 | 2. we detect that the configuration can't be applied. We save it anyway, with a "pending" flag or something. | 18:50 |
| federico1 | 3. If the user starts g-d-p again before rebooting, he gets a warning message | 18:50 |
| federico1 | 4. during relogin, we try to apply the saved configuration. If it had the "pending" flag and it succeeds, we just clear the flag. If it had the flag and it fails, we pop up an error box. If it didn't have the flag, we do whatever we currently do | 18:51 |
| federico1 | would that work? | 18:51 |
| federico1 | (hmmm, I guess you *do* need to save a "known good" configuration somewhere in case it fails after reboot) | 18:51 |
| federico1 | then you don't need a "pending" flag at all; you could use the presence of that "known good" backup as the flag itself | 18:52 |
| * federico1 wonders if he's talking out of his ass or if this makes sense | 18:52 | |
| tseliot | federico1: it does make sense | 18:52 |
| federico1 | tseliot: nice - generally I prefer to rely on as little "external" processes as possible, and the new gnome-session scares me :) | 18:54 |
| tseliot | in any case we could check the framebuffer size (among other things) before we try to apply the settings | 18:54 |
| federico1 | yeah | 18:54 |
| federico1 | tseliot: the X folks at Red Hat are working on making the drivers support on-the-fly configuration of the virtual size, so hopefully this code will be less necessary in the future | 18:55 |
| tseliot | federico1: BTW it looks like gnome_rr_config(save) only pretends to save my settings... | 18:55 |
| federico1 | I need to poke suse's X guys to see if we can do the same for radeonhd on time | 18:55 |
| tseliot | federico1: framebuffer reallocation would be nice but I don't know when it will be available | 18:56 |
| tseliot | but yes, I agree with you on this | 18:56 |
| tseliot | oh, I guess I forgot to set the several output->on to TRUE | 18:58 |
| * tseliot tries to build it again | 19:01 | |
| tseliot | federico1: I was right: I forgot to output->on to TRUE. It works well now. | 19:04 |
| bryce | james_w, tseliot: it's a very interesting idea to include EDID in the Screen Resolution GUI, however it'd be a lot of work for (IMHO) relatively modest benefit compared with using read-edid. | 19:04 |
| bryce | james_w, tseliot: so I'd definitely take a patch to implement it, but wouldn't work on it myself | 19:05 |
| tseliot | bryce: I would like to take a look at it for Intrepid+1 | 19:06 |
| bryce | james_w, tseliot: my immediate thougth would be to steal code from read-edid, however as we looked into the other day, it only works on i386. There's also EDID parsing code in the X server that might be usable. | 19:07 |
| tseliot | bryce: can't we steal code from nvidia-settings? | 19:07 |
| tseliot | so as to extract the bin file and then specify the path to the edid file in the xorg.conf? | 19:08 |
| tseliot | I haven't read the code yet though | 19:10 |
| bryce | wgrant: the patches for 207781 look good to me | 19:11 |
| * tseliot > dinner. bbl | 19:13 | |
| bryce | tseliot: oh maybe, I'm not familiar with the nvidia-settings internals. It's FOSS? | 19:15 |
| jcristau | the server exposes the edid string as a randr output property, if available, so you'd just have to parse that | 19:16 |
| bryce | jcristau: ah even better | 19:45 |
| tjaalton | tseliot: "nvidia: Multiple versions in DKMS. Unsure what to do. Resolve manually. | 20:08 |
| tjaalton | tseliot: that's what I get when reinstalling the kernel | 20:08 |
| tjaalton | tseliot: and the driver manager doesn't list any prop. drivers in use | 20:09 |
| bryce | heya tjaalton | 20:10 |
| tjaalton | hi bryce | 20:10 |
| bryce | tjaalton: btw I've committed the change to replace displayconfig-gtk | 20:13 |
| bryce | tjaalton: this introduces a simple new menu (using zenity) to allow the user to select from some troubleshooting/configuration steps. It's just some simple bash stuff, but if you have time to review it I'd appreciate your thoughts on it. | 20:14 |
| tjaalton | bryce: ok, cool. I'll have a look | 20:15 |
| tjaalton | btw, the commit included adding xinput to xorg deps, and nothing on the changelog about the zenity stuff :) | 20:16 |
| bryce | you can safely execute the failsafeXinit as non-root to see how it looks | 20:16 |
| tjaalton | in X? | 20:16 |
| bryce | yes | 20:16 |
| bryce | I noticed I forgot the changelog and just added it | 20:17 |
| tjaalton | ah, ok | 20:17 |
| bryce | oh yeah wanted to ask about xinput as a dep, vs. adding to seeds (which I'm not sure how to do) | 20:17 |
| tjaalton | closed a bunch of synaptics bugs today because of the properties support | 20:17 |
| tjaalton | this will do | 20:18 |
| bryce | cool | 20:18 |
| bryce | yeah I sent in a patch to add some man page entries for the properties stuff for xinput | 20:18 |
| tjaalton | xinput might be a candidate in some x11- bundle | 20:18 |
| bryce | however I've not yet been able to get those routines to work on my system, just give X errors, not sure why | 20:18 |
| tseliot | bryce: yes, nvidia-settings is GPL | 20:24 |
| bryce | tseliot: see jcristau's comment above - libXrandr provides the parsed edid info | 20:25 |
| bryce | tseliot: although I'm not certain if the bug report wishes the parsed or raw edid. But in the latter case I'm sure we could just tap it in. | 20:25 |
| bryce | er, s/we/whomever works on this/ ;-) | 20:26 |
| tseliot | tjaalton: read this: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/263528/comments/1 | 20:27 |
| ubottu | Launchpad bug 263528 in nvidia-graphics-drivers-177 "Intrepid: Latest update destroys X server configuration on MacBook Pro (Nvidia GeForce 8600M GT, nvidia-glx-177)" [Undecided,New] | 20:27 |
| tseliot | bryce: I think I saw something about edid in the gnome control panel. I think it uses randr. I'll have a look at it | 20:28 |
| * bryce grumbles at git | 20:31 | |
| bryce | heh, it seems like every time I fiddle with the xorg-server git I end up having to toss my tree and recheckout from scratch | 20:34 |
| bryce | sometimes it seems like using git makes it all more work than not using any vcs | 20:35 |
| tjaalton | tseliot: umm, kernel-* is a symlink to 177.70/<kver>, should I remove that as well? | 20:35 |
| tjaalton | tseliot: ok. now the directory is empty, even after reinstalling the source | 20:36 |
| tjaalton | no errors from dkms | 20:37 |
| tseliot | tjaalton: try manually with | 20:38 |
| tseliot | sudo dkms build -m nvidia -v 177.70 -k $(uname -r) | 20:38 |
| tseliot | sudo dkms install -m nvidia -v 177.70 -k $(uname -r) | 20:38 |
| tseliot | oh and make sure that the headers for your kernel are installer | 20:40 |
| tseliot | installed | 20:40 |
| tjaalton | headers are installed, no errors from the build but no modules in /lib/modules or /var/lib/dkms | 20:41 |
| bryce | $ git clone ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git | 20:43 |
| bryce | Initialized empty Git repository in /home/bryce/src/xorg-server/xorg-server/.git/ | 20:43 |
| bryce | ssh: connect to host alioth.debian.org port 22: Connection timed out | 20:43 |
| bryce | fatal: The remote end hung up unexpectedly | 20:43 |
| bryce | fetch-pack from 'ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git' failed. | 20:43 |
| tjaalton | tseliot: oh wait, now I got the modules after all (forgot 'install') | 20:43 |
| tjaalton | bryce: do you always clone the repo? git fetch would be faster | 20:44 |
| tjaalton | I mean when updating the local copy | 20:44 |
| tseliot | tjaalton: ok. The problem shouldn't happen any more with new updates of the driver | 20:45 |
| bryce | tjaalton: yeah I always try that first, but git always messes it up | 20:45 |
| tjaalton | git fetch; git rebase origin/ubuntu | 20:46 |
| bryce | usually I remember to update only after I've made some minor change, and git can't handle having uncommitted changes, tries to do a merge, etc. | 20:46 |
| bryce | yeah tried all that, ended up getting 2 screenfuls of error messages | 20:46 |
| bryce | well, s/fetch/push/ | 20:46 |
| bryce | I think I'm spending more time futzing with git than it actually took to make the patch :-P | 20:47 |
| tjaalton | sure you get conflicts if you have local changes and upstream has moved on | 20:47 |
| jcristau | you need commit your local changes before rebasing | 20:47 |
| tjaalton | but that should normally involve only the changelog | 20:47 |
| jcristau | or stash them | 20:47 |
| bryce | jcristau: yep did that | 20:47 |
| bryce | the git commit -a seemed to work correctly | 20:48 |
| tjaalton | tseliot: so the package was faulty? | 20:48 |
| bryce | then I did a 'git rebase' and it said | 20:48 |
| bryce | fatal: Needed a single revision | 20:48 |
| bryce | invalid upstream | 20:48 |
| bryce | so then I did ` git rebase origin ubuntu` | 20:49 |
| tjaalton | +/ | 20:49 |
| bryce | and then it did a lot of work, and then spewed out several screenfuls | 20:49 |
| bryce | error: patch failed: configure.ac:1032, etc. | 20:49 |
| bryce | so I gave up at that point and tried doing a new git clone | 20:49 |
| bryce | which is timing out | 20:49 |
| bryce | er, the syntax for push is 'git push origin ubuntu' - why would you need a / sometimes, and sometimes not? | 20:50 |
| jcristau | because push wants a remote | 20:51 |
| tjaalton | you are pushing the local ubuntu to remote called 'origin' | 20:51 |
| jcristau | rebase wants a branch | 20:51 |
| jcristau | 'origin' in push means git.debian.org:/git/pkg-xorg/whatever, 'origin/ubuntu' in rebase is 'the local copy of origin's ubuntu branch' | 20:52 |
| bryce | in any case, it still doesn't work | 20:52 |
| bryce | xorg-server-ubuntu-git-broken$ git rebase origin/ubuntu | 20:52 |
| bryce | mkdir: cannot create directory `.dotest': File exists | 20:52 |
| jcristau | right, because you're in the middle a failed rebase | 20:53 |
| tjaalton | rebase --abort | 20:53 |
| bryce | I remove that directory and rerun it, and it shows a bunch of things "need merge" which I didn't change | 20:53 |
| tjaalton | then start over | 20:53 |
| bryce | $ git rebase --abort | 20:53 |
| bryce | No rebase in progress? | 20:53 |
| tjaalton | hmm, would git reset --hard <id> work? | 20:53 |
| tjaalton | <id> being the commit-id of last clean commit | 20:54 |
| jcristau | yeah removing .dotest would have confused it | 20:54 |
| jcristau | so, 'git reset --hard HEAD', i guess | 20:54 |
| tjaalton | oh, HEAD works too | 20:54 |
| bryce | hrm, git rebase origin/ubuntu is still erroring | 20:56 |
| jcristau | what does it say? | 20:56 |
| bryce | ok tell you what, I'll just email you the patches | 20:56 |
| tjaalton | don't give up :) | 20:56 |
| bryce | jcristau: trailing whitespace errors, couple conflicts, etc. | 20:57 |
| jcristau | trailing whitespace is just a warning | 20:57 |
| jcristau | conflicts need to be fixed up anyway | 20:57 |
| jcristau | if some files were modified locally and remotely | 20:57 |
| tjaalton | bryce: also, make sure to always clean up after using the tree for building debs :) | 20:57 |
| bryce | oh I didn't know you couldn't do that... that's like my principle use for it | 20:58 |
| tjaalton | debuild clean works | 20:59 |
| tjaalton | or equivalent | 20:59 |
| bryce | ohh, no I don't use it for building debs, just dsc's | 20:59 |
| bryce | I use pbuilder for making the debs, so that all should be fine. | 21:00 |
| tjaalton | right | 21:00 |
| bryce | but if you have to do cleanups after making a .dsc, that'd be irritating | 21:00 |
| tjaalton | nope, it cleans before building dsc | 21:00 |
| jcristau | dpkg-source -S runs clean first, so no | 21:00 |
| jcristau | err | 21:00 |
| jcristau | i mean dpkg-buildpackage -S | 21:01 |
| tjaalton | bryce: failsafeXinit looks nice. some functions unimplemented, but still | 21:05 |
| tseliot | tjaalton: yes, it was. It didn't clean the DKMS tree when the driver was updated. The current release is no longer affected by the problem however the DKMS has to be cleaned manually | 21:12 |
| tjaalton | tseliot: sounds like the package should clean those up in the preinst.. | 21:16 |
| tseliot | tjaalton: this might break the modules of other kernels. I'll think about a sensible way to do it | 21:18 |
| tjaalton | remove everything <177.70 | 21:23 |
| tjaalton | strange that it didn't complain before. I had four or five different versions there | 21:24 |
| tseliot | tjaalton: yes, something like that | 21:52 |
| bryce | tjaalton: I've done up a simple patch for #247195 | 22:21 |
| bryce | tjaalton: assuming we don't want to just disable the code entirely for now | 22:21 |
| wgrant | tjaalton: I have. My first significant adventure into Xlib, but I think I got it right. | 22:52 |
| wgrant | bryce: Shall I poke somebody else to upload those patches now you've given your +1? | 23:04 |
| bryce | wgrant: seb128 would be a good guy to ask. If he's busy but thinks they're ok too, I can do the upload. | 23:05 |
| wgrant | bryce: I asked him last night, and he told me he didn't know much about it and to ask you. | 23:05 |
| wgrant | But I suppose now I've your ack he should be OK with uploading it. | 23:06 |
| bryce | ok great | 23:42 |
| pwnguin | xorg.conf should still work, correct? | 23:46 |
| bryce | yes | 23:46 |
| pwnguin | okie. someone in +1 is complaining that it doesn't work; thought i'd check it wasn't intended behavior | 23:47 |
| bryce | "doesn't work" is such a vague symptom | 23:48 |
| pwnguin | "changes have no effect" seems specific to me | 23:53 |
| bryce | yes, but you didn't say that ;-) | 23:54 |
| bryce | also, which changes? some changes certainly should work, others (like input device settings) might not | 23:54 |
| bryce | also there are various things that can override some settings like preferred resolutions | 23:54 |
| pwnguin | im torturing that information out right now | 23:54 |
| bryce | some options are no longer provided as user modifyable, so those could also seem to have no effect | 23:55 |
| bryce | modifiable | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!