| === Amaranth_ is now known as Amaranth | ||
| lucazade | Hi! Can anyone enlighten me on this bug 726369? There is also a video with the issue attached to bug report | 09:20 |
|---|---|---|
| ubot4` | Launchpad bug 726369 in xorg-server "graphical glitches in menu (natty) (affects: 4) (heat: 47)" [Undecided,New] https://launchpad.net/bugs/726369 | 09:20 |
| RAOF | Hm. That should probably be filed against xorg-server in Ubuntu :) | 09:32 |
| RAOF | lucazade: Does that manifest with unity/compiz? | 09:34 |
| lucazade | RAOF it manifests only with metacity.. with compiz is not visible | 09:35 |
| RAOF | Yah, suspected as much. | 09:35 |
| lucazade | tried clean installation on different machines.. same issue | 09:36 |
| RAOF | How about if you turn on metacity compositing? | 09:37 |
| lucazade | let me try! | 09:37 |
| lucazade | still present | 09:38 |
| tjaalton | i see that with savage | 09:39 |
| lucazade | where is the issue? who is responsible? | 09:39 |
| lucazade | which component i mean | 09:40 |
| RAOF | Either X or the driver, I'd guess. | 09:41 |
| lucazade | I can reproduce it with every gfx card (gts250, radeon 7500, gma500, vbox) | 09:42 |
| lucazade | i've seen it when xorg 1.9.99 came out | 09:42 |
| RAOF | By that I mean either X or the driver could backfill pixmaps. | 09:42 |
| RAOF | gma500! Lucky man :) | 09:42 |
| lucazade | lol really lucky | 09:43 |
| lucazade | pixman maybe? | 09:43 |
| tseliot | RAOF: are we still using that patch to make X backfill pixmaps? | 09:48 |
| tjaalton | wasn't it reverted upstream | 09:49 |
| tjaalton | in 1.10-branch | 09:49 |
| RAOF | tseliot: Nope. | 09:50 |
| tseliot | ah, if it was reverted then I have no clue ;) | 09:50 |
| tjaalton | hmm not that one, but post-1.10 there's this: http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.10-branch&id=edcf115800fef79d956c8e3d3e3c46a30cf77538 | 09:52 |
| === yofel_ is now known as yofel | ||
| cnd | bryceh, RAOF: I've had two people now complain about the new kinetic scrolling in synaptics | 19:43 |
| cnd | because of the "scroll events as buttons" interface, it does wonky things when you have kinetic scrolling and then press a modifier key like ctrl | 19:44 |
| cnd | if you see more people complain about it, we should consider disabling it by default in an xorg.conf.d snippet | 19:45 |
| bryceh | cnd, ok | 19:59 |
| bryceh | cnd, just "argh change!" type complaints, or definite usability regressions? | 19:59 |
| cnd | there is a real bug that is exposed | 20:00 |
| cnd | but there's no way to fix it | 20:01 |
| cnd | other than completely overhaul scrolling in X | 20:01 |
| cnd | I'll try to explain :) | 20:01 |
| cnd | with kinetic scrolling, if you flick two fingers on a trackpad to scroll, the momentum continues the scrolling behavior for a bit | 20:01 |
| cnd | so scroll button events are sent every so often, slowing down as though there's a friction force | 20:02 |
| bryceh | ah | 20:02 |
| cnd | if you flick like that, and the scroll is still going, then you press the ctrl button, something unexpected may happen | 20:02 |
| cnd | like zooming | 20:02 |
| cnd | to be fair, os x has issues here too | 20:03 |
| cnd | for example, if you have a magic mouse with kinetic scrolling on | 20:03 |
| cnd | you can flick it to scroll | 20:03 |
| cnd | and move your mouse to a different window | 20:03 |
| cnd | and the scroll will continue in the new window | 20:03 |
| cnd | which is probably not intended | 20:03 |
| cnd | it's just a corner case that shows how broken server side scroll handling is :) | 20:03 |
| bryceh | yeah | 20:03 |
| bryceh | mmrph threaded scrolling | 20:04 |
| cnd | hopefully we can get utouch integrated into toolkits in the next cycle to fix this | 20:04 |
| bryceh | cnd, for now could you add a note about this to the release notes? | 20:04 |
| cnd | bryceh, how do I do that? | 20:05 |
| bryceh | I agree at this stage it sounds unlikely to be easily fixable | 20:05 |
| cnd | bryceh, there's one course we could do: disable kinetic scrolling by default | 20:05 |
| cnd | but I'd only advocate that if enough people complain | 20:05 |
| bryceh | cnd, its a wiki page just edit https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview and add a note in the appropriate section | 20:06 |
| cnd | ok | 20:06 |
| bryceh | or maybe add a section after Graphics and display | 20:06 |
| bryceh | "Mice and Keyboards" or some such | 20:07 |
| bryceh | would be nice to call it "Input devices" but that's probably too jargonny | 20:07 |
| cnd | I wonder if it wouldn't be better to just throw it into graphics and display | 20:09 |
| cnd | it's an X display system issue, though the categorization is jargony too | 20:10 |
| bryceh | sure that'd be fine | 20:11 |
| bryceh | I need to comb through that list and take out issues we've solved lately. that should condense it into less of a wall of bullets | 20:12 |
| cnd | heh | 20:12 |
| bryceh | RAOF, what do you think we should do about bug #710762? I'm still sort of on the fence | 21:44 |
| ubot4` | Launchpad bug 710762 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "Middle mouse button no longer works (affects: 3) (heat: 88)" [High,Triaged] https://launchpad.net/bugs/710762 | 21:44 |
| RAOF | So, we have the option of adding unnecessary latency to all mouse clicks if we turn emulation back on. | 21:49 |
| RAOF | Or some people don't get middle-mouse clicking. | 21:49 |
| RAOF | Actually, we had a third option, didn't we - quirk on emulation for known 2-button mice? | 21:50 |
| bryceh | yeah | 21:51 |
| bryceh | fwiw, given that there's been almost zero complaints since we made the change, I'm a lot less worried about if we just leave the change in | 21:52 |
| RAOF | It's not exactly an obvious feature :) | 21:52 |
| bryceh | I'm almost to a point of saying just plunk a comment about it in the release notes and call it done | 21:52 |
| bryceh | if we have a way to quirk the 2-button mice, then maybe we could slap some bug handling directions in wiki for crafting quirks and leave it at that | 21:53 |
| RAOF | That seems reasonable to me. | 21:54 |
| RAOF | The qurik would be a udev tag + xorg.conf snippet, right? | 21:55 |
| jcristau | 2 button mice exist? | 21:55 |
| bryceh | RAOF, something like that | 21:55 |
| RAOF | jcristau: Apparenty so. Cannonical even sells one! | 21:55 |
| jcristau | heh | 21:55 |
| bryceh | http://shop.canonical.com/product_info.php?products_id=643 | 21:56 |
| tjaalton | bryceh: I'd go with that option (leave it as-is, add a not to the relnotes) | 21:56 |
| bryceh | tjaalton, RAOF, ok if either of you can give me the details on how to do the quirks I'll take care of writing it up and closing out the bug | 21:57 |
| tjaalton | the snippet is in the evdev commit | 21:58 |
| tjaalton | ..and on the bug :) | 21:59 |
| tjaalton | that's all there is, no need for udev rules | 21:59 |
| RAOF | But that snippet will apply to everything, right? | 22:00 |
| tjaalton | it could match the identifier | 22:00 |
| RAOF | The udev rules are so that you can add a IM_A_STUPID_TWO_BUTTON_MOUSE tag and have the snippet only apply when that tag is found. | 22:00 |
| tjaalton | but there is no way to know when to set that | 22:00 |
| jcristau | RAOF: doesn't really matter, i think, people with multiple mice can live with the latency for the 3 button one | 22:00 |
| tjaalton | automatically, i mean | 22:01 |
| RAOF | tjaalton: Right. We'd just accumulate a bunch of matches to apply that to. Although if the xorg.conf snippet has enough data to weed those out by itself, that would be easier. | 22:02 |
| tjaalton | RAOF: yeah, the same could be done just on the xorg.conf snippet. but if it's left for the user to set, we can just point to the generic one | 22:03 |
| tjaalton | sigh @ spurious doubleclicks | 22:04 |
| bryceh | what do we match on? | 22:06 |
| tjaalton | MatchIsPointer | 22:07 |
| tjaalton | is what the bug/commit has | 22:07 |
| bryceh | no, how do we distinguish between a mouse that needs the snippet from one that doesn't? | 22:08 |
| RAOF | But in this case, we'd want to match on a hardware identifier. | 22:08 |
| bryceh | like, we know the ubuntu mouse needs it, so how do we identify when one of those is plugged in? | 22:08 |
| bryceh | as opposed to requiring the user always having to manually paste the file in themselves | 22:08 |
| tjaalton | MatchProduct | 22:08 |
| bryceh | what's that match against? lsinput out? | 22:08 |
| tjaalton | for instance | 22:10 |
| RAOF | tjaalton: How many product ids are going to clash? | 22:10 |
| tjaalton | depends :) | 22:10 |
| tjaalton | MatchUSBID uses ids | 22:11 |
| tjaalton | MP the product name | 22:11 |
| tjaalton | finer grained control with udeb tagging and MatchTag | 22:12 |
| tjaalton | udev | 22:12 |
| RAOF | Given that this mouse identifies itself as “Logitech USB wheel mouse”, I feel confident in saying that matching on product name is likely to have overlaps :) | 22:12 |
| jcristau | MatchProduct "PS/2 Mouse" ftw | 22:13 |
| RAOF | Heh. | 22:13 |
| tjaalton | yes, so if we really are going to ship a snippet for the two button mice, it should be by using udev & MatchTag | 22:13 |
| tjaalton | but I thought it was about the general snippet for the relnotes | 22:13 |
| bryceh | for the relnotes I'll just point to the bug report | 22:15 |
| bryceh | or the wiki page | 22:15 |
| tjaalton | the udev rule might even be upstreamable | 22:16 |
| bryceh | but I've a feeling users are mostly going to consider "write xorg.confage" to be the same as not having a solution | 22:16 |
| tjaalton | solution to what?-) | 22:16 |
| bryceh | tjaalton, solution to their two button blues | 22:17 |
| tjaalton | we can't please everybody | 22:17 |
| bryceh | true, but we can choose whether to support the hardware we sell at canonical.com ;-) | 22:19 |
| RAOF | That's easy. We just ship an appropriate udev rule for it :) | 22:19 |
| tjaalton | yes, so udev rule & xorg.conf snippet to evdev should cover it | 22:19 |
| tjaalton | and that's easy to expand | 22:19 |
| bryceh | alright great, what's the udev rule? | 22:21 |
| seb128 | bryceh, hey | 22:22 |
| RAOF | I'd start with the rule in synaptics. | 22:22 |
| seb128 | bryceh, so that bug about memory usage issue on nvidia due to cairo | 22:23 |
| tjaalton | bryceh: I can create one, if only someone with the mouse can provide a dump of udev | 22:23 |
| seb128 | #725434 | 22:23 |
| bryceh | tjaalton, thanks | 22:23 |
| seb128 | bryceh, it's due to build cairo with gl | 22:23 |
| bryceh | seb128, ok, you can close the bug report, probably not worth worrying about - seems to not cause any serious problems. | 22:25 |
| seb128 | bryceh, it's the second tradeoff we get from building cairo with gl (it also brings some extra things on the CD) | 22:25 |
| seb128 | bryceh, you think? it seems it's going to impact some users | 22:26 |
| seb128 | bryceh, I'm pondering suggesting we should roll back from that for this cycle | 22:28 |
| seb128 | while having wayland in universe is nice it's of no real user for most users | 22:28 |
| seb128 | seems the cost on the default installation is not worth the win | 22:28 |
| seb128 | like we impose extra depends on the CD and extra memory usage for some nvidia users just to be able to get something in universe that is of no real benefit to any user | 22:29 |
| seb128 | I'm open to comments from people there though or to discussion | 22:29 |
| RAOF | I wouldn't have any qualms about dropping wayland from universe. Then again, I didn't do the work to *put* it there :) | 22:31 |
| bryceh | seb128, well, I'd have qualms, it was a lot of work to get it enabled | 22:31 |
| RAOF | Although we'll have to deal with this cairo-gl problem sooner or later anyway, so it should be re-enabled once oneiric is open. | 22:32 |
| seb128 | bryceh, the work is not wasted, we can have wayland in a ppa this cycle and bring i back next cycle | 22:32 |
| seb128 | i->it | 22:32 |
| seb128 | it's not like the actual upload to universe what was costed much or that the review comments will not be useful for next cycle | 22:33 |
| bryceh | seb128, no, it would be wasted; the whole point was to make it easy for people to install it, and making libcairo not have gl forces them back to rebuilding everything from git | 22:33 |
| seb128 | or to use a ppa? | 22:34 |
| bryceh | no, a ppa wouldn't work | 22:34 |
| bryceh | I mean, it has been too much effort to maintain it in a ppa for natty | 22:34 |
| seb128 | who is going to want to install something as new as wayland using a snapshot from a stable distro | 22:34 |
| bryceh | every time libcairo has a change, it has to be re-updated in the ppa | 22:34 |
| seb128 | well, once natty turn stable it's not going to happen a lot | 22:34 |
| seb128 | you might have to 2 trivial uploads if we sru a fix or two | 22:35 |
| bryceh | seb128, what are those depends you think it added? | 22:36 |
| seb128 | it seems weird to me that people who want to try wayland will be happy to get an old version rather than a daily or recent build | 22:36 |
| seb128 | I'm not on my natty box right know to check, we tracked it with pitti after a3, some extra gl things | 22:36 |
| seb128 | let me check if I find the irc log from irclogs.u.c | 22:37 |
| bryceh | seb128, the thing they're happy about is not having to rebuild mesa, cairo, etc. etc. from git. It's not that they prefer an old version, it's that there is a packaged version at all | 22:37 |
| bryceh | seb128, further, this is viewed by upstream as a contribution ubuntu has made for upstream; if it is disabled after all then it makes us look silly | 22:38 |
| RAOF | Do we have any idea of what the memory is used for? IIUC, applications need to explicitly select a GL surface for any GL to be used - is this just overhead from *linking* to nvidia's libGL? | 22:40 |
| seb128 | ok, I don't find it in the log, it was something libglish | 22:40 |
| seb128 | one of the libcairo2 libelg or libgl depends I guess | 22:41 |
| seb128 | bryceh, ok, fine, I will think about it, you seem to really care about it | 22:41 |
| bryceh | seb128, ok thanks | 22:42 |
| seb128 | I still think it's not a fair tradeoff for our users, we impact the default installation and nvidia memory use for something which is not user ready | 22:42 |
| RAOF | seb128: I'd guess it's libegl1-mesa that you're thinking of. | 22:42 |
| seb128 | those who want to try wayland are probably really tech users | 22:42 |
| seb128 | RAOF, could be yes | 22:42 |
| bryceh | RAOF, I've wondered the same - it seems there may be a real bug there, non-GL apps shouldn't be affected by the mere presence of GL functionality | 22:42 |
| seb128 | I can't really check now if that would be installed without cairo bringing it in | 22:43 |
| RAOF | bryceh: Right. There is a real bug there which we'll need to either fix, or ensure gets fixed, at some point fairly soon. | 22:43 |
| RAOF | I'd be surprised if anything else pulled in libegl1. I'm surprised *cairo* pulls in egl! | 22:43 |
| seb128 | ok | 22:44 |
| seb128 | so that was likely it | 22:44 |
| seb128 | is that any way we could figure if that memory use issue is affecting every nvidia users? | 22:50 |
| seb128 | and maybe to get if figured for natty? | 22:50 |
| * RAOF hunts around for his spare geforce 6600 | 22:51 | |
| seb128 | I'm not sure we should spend time on that for natty rather than focus on unity | 22:51 |
| seb128 | but if that's affecting nvidia users and not only one of them I suggest that's something we need to address one way or the other | 22:51 |
| RAOF | It looks like it should be easy to tell if it affects a given system, so I can check mine. | 22:52 |
| bryceh | RAOF, tjaalton: https://wiki.ubuntu.com/X/Quirks#Input%20Quirks | 23:16 |
| * RAOF wonders whether his freshly broken graphics are due to the card or the drivers. | 23:22 | |
| RAOF | Aaah. I missed a power connector! | 23:23 |
| * RAOF grumbles softly about the insane power requirements of gpus. | 23:27 | |
| bryceh | they may soon require a power supply of their own | 23:28 |
| RAOF | This is an old card, too. | 23:32 |
| RAOF | Merely a 7800GT. | 23:32 |
| RAOF | Dear lord it's loud, too. | 23:32 |
| RAOF | Hm. Doesn't appear to like plymouth much, either. | 23:33 |
| RAOF | Mmm, the glorious whiteness of vesafb. | 23:34 |
| RAOF | :( And it doesn't parse my edid. | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!