| === superm1|away is now known as superm1 | ||
| tjaalton | bryce: btw, I filed a sync request for libx11-1.1.5, bug 273471 | 05:21 |
|---|---|---|
| ubottu | Launchpad bug 273471 in libx11 "Please sync libx11 1.1.5-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/273471 | 05:21 |
| bryce | tjaalton: great, I've +1'd it | 07:51 |
| tjaalton | bryce: nice, thanks | 07:52 |
| tjaalton | I'll subscribe -archive since it's a bugfix release | 07:52 |
| tjaalton | pop your champagne bottles open, we got 2000 bugs! | 09:19 |
| tseliot | \o/ | 09:57 |
| Ng | tjaalton: do you know if anyone is working on xinput config gui stuff? is it just going to go into the existing gnome capplets? | 10:08 |
| tjaalton | Ng: no I don't know of anyone doing that, and yes, it should go in the existing capplet I think | 10:10 |
| Ng | well that rules me out, those things will be in C. I was just pondering hacking something up in python which would discover the devices and their properties and let you twiddle them, but it should really be a nice interface that hides all the scary numbers ;) | 10:11 |
| tjaalton | yeah the xinput interface isn't that friendly | 10:11 |
| Ng | I dunno what the underlying xinput API is like, but the commandline tool doesn't seem to expose enough information - like for an int value it doesn't tell you how large an int it is, but to set it you need to know | 10:11 |
| tseliot | Ng: I would like to write a UI for xinput stuff | 10:52 |
| tseliot | I can do it for GNOME and KDE | 10:53 |
| tseliot | I hope to be able to do it in time for Ubuntu 9.04 | 10:53 |
| Ng | cool :) | 10:53 |
| Ng | a quick look at the existing gnome input capplets suggests to me that they are entirely unsuitable for this | 10:54 |
| Ng | in a world of multiple input devices and per-device properties, a single capplet for setting things for a single mouse no longer makes sense | 10:54 |
| Ng | I'd suggest that things have global defaults, but be overridable for individual devices, and some part of the desktop would receive events for these devices being connected and apply the appropriate settings the user had previously chosen | 10:55 |
| tseliot | if I complete input support for X-Kit we can configure devices with FDI files too | 10:56 |
| Ng | (e.g. I'm thinking about acceleration - a single value can't possibly hope to make sense for a laptop with a touchpad, trackpoint and USB mouse) | 10:56 |
| tseliot | yes, that's the idea | 10:57 |
| Ng | :) | 11:04 |
| Ng | I'll keep quiet now, I'm sure that more capable brains than mine will get it right :) | 11:04 |
| === superm1 is now known as superm1|away | ||
| bryce | Ng: would you be interested in rigging up a prototype UI? I think part of the problem is no one is sure what the tool should look like, and we need to start gathering some conceptual stuff (regardless of language) so people have something to stimulate ideas | 16:01 |
| Ng | bryce: perhaps. Is there a way to send the appropriate X calls from python? :) | 16:02 |
| Ng | for some reason I have a weird enjoyment of auto-generating UIs in python | 16:02 |
| bryce | there probably isn't a python binding for libxi-dev | 16:03 |
| bryce | but you could probably review its api | 16:04 |
| bryce | but even if the prototype didn't consider how it hooks to the backend and just focused on conceptualizing the UI, that'd help | 16:05 |
| Ng | yeah I figured there would be no bindings, I was kind of hoping there was a generic way to request this stuff via some X binding ;) | 16:05 |
| tseliot | I was planning to use swig or something similar to access xinput from python. We'll see | 16:11 |
| Ng | "This section provides information about the XInput API, which allows applications to interact with the Xbox 360 Controller when it is connected to a Windows" dear google.... fail | 16:11 |
| jcristau | i thought someone did a python binding generator from xcb protocol descriptions | 16:12 |
| tseliot | jcristau: that would help | 16:13 |
| tseliot | Ng: /usr/include/X11/extensions/XInput.h perhaps? | 16:13 |
| Ng | tseliot: yeah, I was actually just googling to see if there are any nice pages which have more of an overview of xinput | 16:13 |
| Ng | the output of "xinput list" shows a bunch of stuff which I would guess has no place in a user config system | 16:14 |
| tseliot | Ng: aah, some proper docs | 16:14 |
| Ng | e.g. "Video Bus" - I have no idae why that appears twice in a list of input devices ;) | 16:14 |
| jcristau | Ng: because it appears twice in /proc/bus/input/devices | 16:24 |
| jcristau | and claims to have keys | 16:24 |
| Ng | so I immediately wonder how on earth a configuration GUI is going to eliminate all of the clearly bogus entries in there | 16:25 |
| Ng | macintosh mouse button emulation is not bogus on certain hardware, but it seems to appear everywhere | 16:25 |
| jcristau | don't try to solve that in the configuration gui. find a way to detect these cases, and don't load evdev for them. | 16:26 |
| Ng | maybe I'll stick to UI mockups or go with my earlier plan of leaving this for smarter brains ;) | 16:30 |
| tseliot | Ng: UI mockups are more than welcome ;) | 16:38 |
| Ng | I almost wonder if talking directly to xinput for the list of devices is a mistake and that hal should have an addon which puts their properties into its tree | 16:40 |
| Ng | but I'm really not very familiar with that kind of thing, so I could be talking nonsense ;) | 16:40 |
| jcristau | talking to hal would be a mistake | 16:40 |
| Ng | I'll take your word for that, but out of interest - why? | 16:41 |
| jcristau | because you're configuring your X server, and you already have a way to talk to it, it's the X11 protocol | 16:42 |
| jcristau | talking to hal on the machine where the X client is running achieves nothing, since the x server might live somewhere else entirely, and even if not you'd need some kind of authorization mechanism. which you already have with Xauth if you communicate via X11 | 16:44 |
| Ng | that's a good point | 16:45 |
| tjaalton | ie. don't try to build a gui for xinput-the-command, but XInput the API | 16:46 |
| tjaalton | just like wgrant did for synaptics ;) | 16:47 |
| tjaalton | although, the API will soon change a bit | 16:47 |
| tseliot | tjaalton: of course I'll wait for the new API ;) | 16:49 |
| === superm1|away is now known as superm1 | ||
| tjaalton | bryce: I'll prepare mesa-7.2 and xserver-1.5.1 for upload | 17:27 |
| bryce | tjaalton: ok; is mesa 7.2 mainly bug fixes? I suspect the last mesa (or else kernel) broke compiz on one of my machines | 18:27 |
| tjaalton | bryce: yes, 7.1 was a devel version, 7.2 is the stable one | 18:59 |
| tjaalton | bryce: what hardware was it where compiz failed? | 19:16 |
| bryce | tjaalton: http://bryceharrington.org/ubuntu/lspci.txt | 19:18 |
| bryce | tjaalton: erf, 255008 has reopened | 19:18 |
| tjaalton | "Eaglelake".. never heard | 19:27 |
| tjaalton | bryce: should be closed again | 19:28 |
| bryce | tjaalton: ok, what should I tell them? | 19:29 |
| tjaalton | muelli is the only one with the problem | 19:29 |
| tjaalton | I'll explain him | 19:30 |
| bryce | ok great thanks | 19:32 |
| bryce | yay, ok I think all intrepid targeted X bugs are closed now | 19:32 |
| bryce | oops maybe not | 19:33 |
| bryce | 247376 is our fglrx one we can't do anything for yet. 179797 is fix committed. hmm... | 19:34 |
| superm1 | any updates from AMD regarding the libstdc++5 business? | 19:34 |
| bryce | superm1: never got a reply to my email :-/ | 19:37 |
| superm1 | -shrug- | 19:37 |
| bryce | next call is in a week; I'll re-raise it then | 19:37 |
| bryce | I suspect they've read it and (hopefully) added to their todo list, but maybe didn't think a reply was needed | 19:38 |
| bryce | I went to dinner with them once and noticed they are major blackberry junkies there | 19:38 |
| bryce | but because the keyboards are so tiny and hard to use, they tended to read waaaay more than they write ;-) | 19:39 |
| superm1 | yeah 90% of the mail i see from mtippet is from BB | 19:40 |
| superm1 | (that's a bit rude for them to be using them during dinner though) | 19:40 |
| bryce | (that was my take too...) | 19:44 |
| bryce | tjaalton: the compiz issue I mentioned earlier is #261080 | 21:41 |
| bryce | tjaalton: (which is a private bug) | 21:41 |
| bryce | upstreamed at http://bugs.freedesktop.org/show_bug.cgi?id=17384 | 21:42 |
| ubottu | Freedesktop bug 17384 in Drivers/DRI/i965 "X hangs up if turning on the virtual effect of gnome" [Major,Reopened] | 21:42 |
| bryce | tseliot: btw, on bug 220563, you should file a new bug with those patches, since that bug is already closed | 21:53 |
| bryce | tseliot: I think you'll need to get seb128's approval on them to go in, since they're a fairly substantial amount of code | 21:53 |
| tseliot | bryce: ok, thanks, I'll do it | 21:54 |
| tseliot | oh seb128 has just entered | 21:54 |
| bryce | tseliot: I'd be happy to sponsor the upload if he is okay with the changes | 21:54 |
| bryce | oh, one note is in the screen-resolution-extra diff, it appears you stepped on james_w's changelog entry; perhaps that could be cleaned up better | 21:55 |
| tseliot | bryce: great. Ok, I'll open another report, attach the patches and bug seb128 again to review them | 21:55 |
| tseliot | bryce: sure, I will fix it | 21:55 |
| tseliot | right, James' entry is missing | 21:57 |
| seb128 | tseliot: where are the changes to review? | 21:57 |
| tseliot | seb128: https://bugs.launchpad.net/gnome-control-center/+bug/220563 | 21:58 |
| tseliot | see the last posts | 21:58 |
| tseliot | seb128: and thanks in advance :-) | 21:58 |
| Ng | tjaalton: is it expected that xinput properties are lost across a suspend/resume? | 22:06 |
| tjaalton | Ng: I'm not sure, sounds like a bug | 22:06 |
| Ng | I've not checked if it's entirely reproducible yet, but I've noticed it twice today and afair I've suspended twice so far | 22:07 |
| tjaalton | mine fails to resume, so can't really test it myself :) | 22:08 |
| Ng | erk | 22:14 |
| Ng | your X61? | 22:14 |
| Ng | I read a bug earlier on one of the 14 bajillion BTS I'm poking around in since this damn e1000e bug appeared, about some variant of e1000 breaking resume. It definitely used to break suspend for me, so I generally unload it on suspend | 22:15 |
| Ng | although I think intrepid has lost the script we put in for hardy to do that | 22:15 |
| seb128 | tseliot: + - bump Standards-Version to 3.8.0 | 22:25 |
| seb128 | why? | 22:25 |
| seb128 | I'm wondering why many people do that, we have no reason to create diff over debian on this number and we make no use of it | 22:25 |
| seb128 | did you verify it conforms to the new standards-version or just updated automatically? | 22:25 |
| seb128 | tseliot: I've to admit I don't like those changes | 22:32 |
| seb128 | that doesn't seem the right way to me | 22:32 |
| === superm1 is now known as superm1|away | ||
| tseliot | seb128: ok, I can revert that change | 22:53 |
| tseliot | seb128: don't you like the other changes either? | 22:53 |
| seb128 | tseliot: several things | 22:53 |
| seb128 | - displaying an error saying to edit the virtual xorg.conf, no | 22:53 |
| seb128 | that's not something user will understand and not something to recommend | 22:54 |
| seb128 | you should rather display a "you need to install this software for that" and maybe add an "install now button" | 22:54 |
| tseliot | seb128: shall I change the message to "sorry, it wasn't possible to apply your settings"? | 22:54 |
| tseliot | ah | 22:54 |
| seb128 | similar to how samba is installed when required for example | 22:55 |
| tseliot | seb128: ah, ok, so I should call APT to install screen-resolution-extra if the user accepts | 22:55 |
| tseliot | good point | 22:55 |
| seb128 | right, or rather synaptic | 22:55 |
| seb128 | maybe ask mvo about it | 22:56 |
| tseliot | yes, I know how to do it | 22:56 |
| tseliot | I can call that stripped down progress dialog | 22:56 |
| tseliot | I did it in another app too | 22:56 |
| seb128 | otherwise I'm not sure to understand why you need a copy of the settings | 22:56 |
| tseliot | seb128: because otherwise you would have to log in and set up screens again as you did before | 22:57 |
| tseliot | why should users do the same thing twice? | 22:57 |
| seb128 | why? can't you write directly the config? | 22:58 |
| seb128 | it'll not be used before next login anyway | 22:58 |
| tseliot | yes but then you will have to restart the xserver | 22:58 |
| seb128 | you have to restart it anyway | 22:58 |
| tseliot | yes but my point is | 22:58 |
| tseliot | that you don't have to set up your screens again after restarting X | 22:59 |
| tseliot | since you have already selected how you would like to have your screens arranged | 22:59 |
| tseliot | and that determines the framebuffer size | 22:59 |
| tseliot | seb128: maybe I'm missing your point. If so, please explain it again | 23:00 |
| seb128 | why would writting the new config directly not work? | 23:00 |
| seb128 | well you write an alternate config now | 23:00 |
| tseliot | ah | 23:00 |
| seb128 | and try to load this one first at next login right? | 23:00 |
| seb128 | why don't you writte directly the normal config, it'll not be applied before the next login anyway | 23:01 |
| tseliot | no, it wouldn't work as the current app won't do anything. It will only try to apply settings without writing anything | 23:01 |
| tseliot | I prefer not to touch the main xml file | 23:01 |
| tseliot | so that if previous settings worked | 23:02 |
| tseliot | we should use them instead | 23:02 |
| tseliot | we should keep using them, I mean | 23:02 |
| tseliot | otherwise, if all the conditions are good | 23:03 |
| tseliot | we apply the desired xml | 23:03 |
| tseliot | for example | 23:03 |
| tseliot | if a certain setup used to work, say, with 2 screens, | 23:04 |
| tseliot | we let the system fallback to that | 23:04 |
| seb128 | alright, it seems a bit weird but why not | 23:05 |
| seb128 | did you discuss that upstream already? | 23:06 |
| tseliot | I sent an email to Soren | 23:06 |
| tseliot | and attached two partial patches | 23:06 |
| seb128 | anyway feel free to get the changes sponsored by somebody once you fixed the "change your xorg virtual setting configuration" thing ;-) | 23:06 |
| tseliot | in the GNOME bugzilla | 23:06 |
| tseliot | seb128: ok, great, I will change it as you suggested | 23:07 |
| tseliot | thanks a lot | 23:07 |
| seb128 | thank you | 23:07 |
| tseliot | :-) | 23:07 |
| jcristau | Ng: the device might be removed by the kernel on suspend, so you'd get a new one on resume | 23:52 |
| Ng | jcristau: is that logged or traceable somehow? | 23:55 |
| Ng | it does seem to be happening every time | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!