[00:04] it seams to be fixed, but I will test it more just in case [00:19] Riotta, cool, yes please test for any regressions or surprises [00:19] yeah [00:48] goodnight === Amaranth_ is now known as Amaranth [18:34] hello [18:39] hello tormod [18:40] hi Riotta, mouse works well? [18:41] well got some problem, but I'm not sure if this patch would fix this problem [18:41] generally it fixes this what was filled in the bug report both xorg/launchpad but I noticied something [18:42] dunno is it just me or is it affect other, need to find somebody to test this [18:43] a possible regression caused by the patch? [18:43] and I'm sure it's related to the same package [18:43] no [18:43] ok [18:43] I think it's not caused by patch [18:44] maybe I will tell you what's this all about [18:45] tormod: can I pm you? [18:46] sure but you can talk about any x issue here also [18:47] ah ok [18:47] it's better here because other people might listen in and can know more about it than I do [18:47] so I got this bug, where my right click events are broken [18:48] it can sound little odd [18:48] but I noticied it after upgrade from jaunty to karmic [18:48] that when I right clicked in program like Gnome Commaner [18:48] where right click can be configured for selecting files [18:49] the right click were badly interpreted [18:49] for example [18:50] I wanted to select one file and xorg saw it like I wanted to click file above not the direct file (dunno if you understand me) [18:50] miss-clicking? [18:51] and I'm sure it's not gnome-commander bug or gnome [18:51] is it reproducible? [18:51] it's related with xserver-xorg-input-evdev [18:51] I can reproduct it [18:52] does it happen when you right-click in for example firefox? [18:52] need find someone to test it [18:52] wait I wanted to say why I think its related to xserver-xorg-input-evdev [18:53] when I filled bug 441408 [18:53] Launchpad bug 441408 in xorg-server "[MASTER] Mouse jumps to bottom corner on click in fullscreen games. New mouses (A4Tech). Related to DGA / DGAMOUSE in SDL." [Unknown,Fix released] https://launchpad.net/bugs/441408 [18:53] I have found that downgrading package xserver-xorg-input-evdev fixes bug from launchpad and I also noticied that this problem with clicking that I had was gone also [18:54] yesterday I thought that this patch will fix that also cause 1.2.2.5 evdev package I had those clicking issues [18:54] but it's ixed only filled bug, so I guess it's not related [18:55] with this bug [18:55] so the mouse pointer does not jump to the wrong spot, but the click take action a bit above the pointer? [18:55] but it's related with package [18:55] yes [18:55] exactly [18:55] it will select two files or one of the above [18:55] in most cases [18:56] I will try firefox but I think best app for reproducing this is gnome-commander or commander like app [18:57] I tried with nautilus but you got big icons there so the clicking precission is other [18:57] even if you will make them smaller [18:57] and "listed" [18:59] can you try "xev", rightclicking outside the square should give only ButtonPress/Release, inside lots of Notify as well [19:01] what I should look for? [19:01] the messages that flow in the terminal window, see if clicking inside/outside the box gives the expected messages [19:02] if clicking just below the box gives the Notify messages, you have reproduced the bug with xev [19:03] ah [19:04] is box border counted as box area? [19:04] yes, AFAICT [19:07] I think I can't reproduce it with xev if I get this right cause inside the box I got additional KeymapNotify even and otuside ButtonPress/Release and MotionNotify [19:10] ok, so you never get KeymapNotify outside (just below) the box? [19:12] if downgrading evdev fixes it, it could look like an evdev bug, but if it is only with one application I don't know [19:12] no I don't get keymapnotify outside [19:13] yes downgrading fixes, I will show you screenshot to image this bug little more [19:13] please file a bug and attach the screenshot there. if anyone else experiences this, they can find your report [19:14] okay [19:16] http://i47.tinypic.com/302oxt0.jpg here, I didn't move mouse when I right-clicked [19:17] I will fill bug report [19:18] and it only happens with your gaming mouse, could you try another? [19:18] I will try another one [19:19] bryce, can you please sponsor 441408? [19:19] sure one minute [19:20] I think it's related only with my mouse [19:20] :< [19:26] but I have noticed that repluging to usb port is fixing this issue [19:26] very strange === albert231 is now known as albert23 === ripps_ is now known as ripps [23:22] > Hi., I'm here to report a serious regression from 9.04 and that it's being systematically misdiagnosed on the Ubuntu forums. Any maintainers responsible for the X.org packages here? [23:27] some are [23:29] esr, sounds like you want to report a bug, please use "ubuntu-bug xorg" [23:30] bryce, did you forget about 441408 ? :) [23:31] tormod: I'd like to kick it around with an X package dev first. It's possible I could have it wrong. [23:31] tormod, oops yeah I did sorry. On it now. [23:31] bryce, what do you think about SRU for it? [23:32] esr: well, this is the place to discuss it, I would throw it out and start the discussion [23:32] Symptom: On a stock Ubuntu 9.04 with Intel 965 card and Samsung 1100DF monitor, X detected its 2048x1536 resolution and used it. On Karmic this fails. [23:33] tormod, yeah maybe ok for an sru although I'd like to see it tested in lucid for a bit first [23:33] bryce, sure [23:34] There's a myth current on your forums that this is an nVidia-specific problem. It's not. It's not even driver level. Here's how I know... [23:34] tormod, do you want to update the description for sru? I'll upload this an ack [23:35] 1) I looked at the X log. The interface to EDID is failing to generate any modelines above bog-standard 1280x104, [23:35] bryce, I'll look at the SRU bureaucracy another day [23:35] tormod, wimp ;-) [23:35] 2) I fixed it by patching in a custom 2048x1536 modeline. [23:36] This is an *Intel* chip. [23:36] Having the autoconfig fail on it is...pretty inexcusable. [23:36] bryce, maybe someone else looks at it in the meantime :) [23:36] tormod, https://wiki.ubuntu.com/StableReleaseUpdates - the Procedure section. [23:37] bryce, I know, I have done this before, that's why I am wise enough to not start at it now :) [23:38] esr, yeah I know of this bug, I think the kernel changed how timings are calculated for modelines [23:38] esr, I've already spoken to the kernel team about it, there is an upstream kernel patch they think may fix the timings [23:38] bryce: What in the frickety-fracking frack has the *kernel* got to do with it? [23:38] I guess a workaround is to run without KMS [23:39] Kernel Mode Setting [23:39] esr: there have been a lot of weird glitches with the move to KMS. In karmic I lost full scaling in certain modes. [23:40] unfortunately the bugs I've looked at don't give enough detail in Xorg.0.log about the timing calculations [23:40] it would be informative to compare a modeline from jaunty with the corresponding one from karmic [23:41] the other thing I'm suspecting with some bug reports is that edid is not being transferred correctly, although that accounts for only a proportion of the bugs [23:48] tormod, sponsored and uploaded [23:48] sorry for the delay, blueprint stuff has been kicking my butt today [23:48] bryce: That's actually my guess -- that is, EDID info is getting lost. [23:50] https://wiki.ubuntu.com/X/Troubleshooting/Resolution has some tips/tools for analyzing the edid [23:50] get-edid is a useful tool [23:56] bryce, thanks! yeah I saw the xorg-triaging blueprint, will keep an eye on that. processing logs etc interests me. [23:57] tormod, cool. yeah I'm sort of mulling over an idea to break out failsafe-x into a separate package and integrate some of the diagnosis tools into that [23:58] oh the things I dream up to do with my imaginary free time [23:59] bryce: Installing read-edid now to check that.