| njh | trying to get a marblemouse working on intrepid (upgraded from hardy) | 06:46 |
|---|---|---|
| njh | two problems | 06:46 |
| njh | first is the button reassignmentL: | 06:46 |
| njh | njh@thestral:~/svn/lib2geom$ xinput set-button-map 6 1 8 3 4 5 6 7 2 9 | 06:46 |
| njh | X Error of failed request: BadValue (integer parameter out of range for operation) | 06:46 |
| njh | Major opcode of failed request: 148 (XInputExtension) | 06:46 |
| njh | Minor opcode of failed request: 29 (X_SetDeviceButtonMapping) | 06:46 |
| njh | Value in failed request: 0xa | 06:46 |
| njh | Serial number of failed request: 13 | 06:46 |
| njh | Current serial number in output stream: 13 | 06:46 |
| njh | the second is that although the scroll button correctly disconnects the cursor movement, it doesn't generate any scroll events | 06:47 |
| njh | here's my props: | 06:47 |
| njh | Device 'Logitech USB Trackball': | 06:47 |
| njh | Device Enabled:1 | 06:47 |
| njh | Middle Button Emulation:1 | 06:47 |
| njh | Middle Button Timeout:50 | 06:47 |
| njh | Wheel Emulation Inertia:10 | 06:47 |
| njh | Wheel Emulation:1 | 06:47 |
| njh | Wheel Emulation X Axis:6, 7 | 06:47 |
| njh | Wheel Emulation Y Axis:4, 5 | 06:47 |
| njh | Wheel Emulation Timeout:200 | 06:47 |
| njh | Wheel Emulation Button:9 | 06:47 |
| njh | Drag Lock Buttons:0 | 06:47 |
| njh | these settings work on intrepid from scratch | 06:47 |
| wgrant | njh: Please don't flood. The xinput problem is probably caused by your failing to understand that it wants a permutation of the buttons. | 06:48 |
| njh | I gave it permutation of the buttons | 06:49 |
| wgrant | There are precisely 9 buttons that X knows about? | 06:49 |
| njh | how would I find out? | 06:49 |
| njh | as I said, the same settings worked on a different machine | 06:49 |
| njh | it's hard to debug this when debuging information is scant and the documentation lacking | 06:50 |
| wgrant | It depends on the mouse, not the machine. | 06:50 |
| njh | it is the same mouse | 06:50 |
| njh | I simply unplugged it from one and moved it to the other | 06:50 |
| wgrant | Are you sure you're giving it the right device ID? | 06:50 |
| njh | but I'll just try again | 06:50 |
| njh | yes | 06:50 |
| njh | yep, it still works | 06:52 |
| njh | so same mouse, both intrepid, same options | 06:53 |
| njh | works fine on machine A (installed from CD) | 06:53 |
| njh | doesn't on machine B (upgrade from vanilla hardy) | 06:53 |
| wgrant | Same architecture? | 06:53 |
| wgrant | No input devices in xorg.conf? | 06:54 |
| njh | both 32 bit x86 | 06:54 |
| njh | all input devices commented out ("commented out by update-manager, HAL is now used") | 06:54 |
| wgrant | 'xinput list' from both machines. | 06:55 |
| wgrant | !pastebin | 06:55 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 06:55 |
| njh | *sniff* how primitive | 06:55 |
| wgrant | Hm? | 06:56 |
| njh | can't copy and paste over remote desktop it seems :( | 06:57 |
| njh | and now it works | 07:01 |
| njh | oh well, bug solved | 07:01 |
| wgrant | Heh. | 07:01 |
| njh | though I wish I could make the hal thing work | 07:01 |
| wgrant | What do you mean? | 07:01 |
| njh | rather than using xinput | 07:01 |
| wgrant | What isn't working about it? | 07:02 |
| njh | I followed the instrutions at: | 07:02 |
| njh | https://help.ubuntu.com/community/Logitech_Marblemouse_USB | 07:02 |
| njh | but the fdi match file doesn't | 07:02 |
| wgrant | Which bit doesn't work? Just the buttonmapping? | 07:02 |
| njh | so I just created a new file.fdi with that xml | 07:03 |
| wgrant | Oh. | 07:03 |
| wgrant | That would do it. | 07:03 |
| wgrant | That's not complete. | 07:03 |
| * wgrant fixes. | 07:03 | |
| wgrant | Add: | 07:04 |
| wgrant | <?xml version="1.0" encoding="ISO-8859-1"?> | 07:04 |
| wgrant | <deviceinfo version="0.2"> <device> | 07:04 |
| wgrant | To the start. | 07:04 |
| wgrant | And: | 07:04 |
| wgrant | </device> | 07:04 |
| wgrant | </deviceinfo> | 07:04 |
| njh | incidently, any reason why that file isn't included in intrepid itself? | 07:04 |
| wgrant | to the end. | 07:04 |
| wgrant | Nobody I know has that hardware, and I wasnt sure if that was appropriate for the ubiquitous configuration. | 07:04 |
| njh | ah, well everyone I mentioned I'd bought it too said they also had one | 07:05 |
| wgrant | I hadn't heard of it until I tried to fix that page. | 07:05 |
| njh | does it hurt to have such stuff? | 07:05 |
| wgrant | Does everybody use the trackball like that? | 07:05 |
| njh | given that it's 545 bytes | 07:05 |
| njh | pretty much | 07:05 |
| njh | it's the way that windows does it | 07:06 |
| njh | ok, I've updated the fdi file | 07:06 |
| wgrant | OK. | 07:06 |
| njh | do I just unplug and replut? | 07:06 |
| wgrant | That should do it, yes. | 07:06 |
| njh | nup | 07:06 |
| njh | where does the errors go? | 07:06 |
| wgrant | Hmmm. | 07:06 |
| wgrant | You could check /var/log/Xorg.0.log | 07:07 |
| wgrant | It's possible that you'll need to restart hal (ie. reboot), but I've never had to. | 07:07 |
| njh | it's finding the mouse, but setting the wrong options | 07:08 |
| wgrant | Is it setting any of them? | 07:08 |
| njh | yes, but to the hard defaults | 07:09 |
| wgrant | You might want to try giving it the full button mapping - that might be why people have said the given fdi file doesn't do that. | 07:09 |
| njh | it's not setting anything atm | 07:09 |
| wgrant | Hmmmmm. | 07:09 |
| njh | should <merge key="input.x11_options.ButtonMapping" type="string">1 8 3 2 9</merge> be a permutation? | 07:09 |
| wgrant | I suspect evdev will want it to be, yes. | 07:09 |
| njh | (and if so, how do I find out the correct number of buttons) | 07:10 |
| wgrant | mouse worked without it, but I'm not sure about evdev. | 07:10 |
| njh | hmm | 07:10 |
| njh | it hasn't set any of the other props though | 07:10 |
| njh | which suggests that it isn't matching | 07:10 |
| wgrant | Does lshal see that same product name? | 07:10 |
| njh | yes | 07:11 |
| wgrant | OK, you might have to restart hal. But don't do that while X is running. | 07:11 |
| njh | no | 07:11 |
| njh | that's bad | 07:11 |
| njh | I wonder if adding that to the existing preferences file would work | 07:12 |
| wgrant | It's possible that hal saw the file, noticed that it wasn't a real fdi file, so is now going to ignore it until you restart it. | 07:12 |
| bryce | wgrant: why not restart hal while X is running? | 07:12 |
| njh | it buggers everything up | 07:12 |
| njh | btdt | 07:12 |
| wgrant | bryce: X has got very very angry with me because of that twice now. | 07:12 |
| wgrant | X wanders away and dies eventually. | 07:12 |
| njh | yeah, that | 07:13 |
| bryce | wgrant: interesting. I've been doing that without issue, although not recently | 07:13 |
| bryce | wgrant: is there a bug about that issue? | 07:13 |
| njh | ok, so deviceinfo tag is once per file? | 07:13 |
| wgrant | bryce: I didn't think it would count as a bug. | 07:13 |
| njh | it's a bit bad I think | 07:13 |
| bryce | wgrant: no? One of the advertised features of all this hal stuff was that hal changes could be made without having to restart X. | 07:14 |
| wgrant | njh: deviceinfo is the top-level element, so yes, only one. | 07:14 |
| wgrant | bryce: I normally don't have to restart hal to make changes to the hal config. | 07:14 |
| njh | nup | 07:14 |
| njh | still no go | 07:14 |
| njh | so it's probably not matching something exactly | 07:14 |
| njh | I wish it would tell me why not | 07:14 |
| wgrant | bryce: Let's see what X does if I restart hal now... maybe brb. | 07:15 |
| njh | a hal reload option might be useful | 07:15 |
| wgrant | Hm. | 07:15 |
| wgrant | X survived that time. | 07:15 |
| wgrant | It doesn't always. | 07:15 |
| njh | no | 07:15 |
| njh | it could be a heisenbug | 07:16 |
| bryce | huh. well, if either of you run into this issue again, please file a bug on it with the logs / error messages. That seems like something well worth getting fixed. | 07:16 |
| njh | restarting hal didn't fix the problem in any case | 07:16 |
| bryce | troubleshooting input-hotplug issues are hard enough without also having X fall to pieces ;-) | 07:16 |
| wgrant | bryce: Sure, will do. | 07:16 |
| njh | yes | 07:17 |
| wgrant | Yep... | 07:17 |
| njh | the doco says match key="@blah" | 07:18 |
| wgrant | njh: Try contains= rather than string= | 07:19 |
| njh | nup | 07:20 |
| njh | I wish I knew exactly what steps are required | 07:20 |
| njh | do I need restart hal after every edit? | 07:21 |
| wgrant | njh: I don't think so. I can just drop a new file in /etc/hal/fdi/policy, replug the device, and have the new setting in place. | 07:21 |
| njh | I don't even know if it is reading the file :( | 07:21 |
| njh | ok | 07:22 |
| njh | is there something I could put in the file which would prove it is being read? | 07:22 |
| njh | perhaps a syntax error... | 07:22 |
| njh | nup, a syntax error does not break it :) | 07:22 |
| wgrant | I don't know how hal works, sorryu. | 07:23 |
| wgrant | -u | 07:23 |
| bryce | I was debugging by diffing lshal output before and after plugging in the device | 07:24 |
| wgrant | That would work. | 07:24 |
| * wgrant just read the email on ubuntu-x about the tablet config UI. | 07:27 | |
| wgrant | All of those things look like they should be exposed through XI device props... | 07:27 |
| tjaalton | morning | 07:27 |
| njh | > input.x11_options.ButtonMapping = '1 8 3 2 9' (string) | 07:27 |
| njh | it's setting the buttons! | 07:28 |
| njh | just nothing else | 07:28 |
| wgrant | Morning tjaalton. | 07:28 |
| bryce | heya tjaalton | 07:29 |
| bryce | wgrant: yeah I'm writing a reply to that thread, it would be great to get your input on it as well | 07:30 |
| njh | I'm wondering whether the x names differ from the xinput names | 07:31 |
| wgrant | bryce: I think we're going to need one awfully big unified gnome-input-properties... | 07:31 |
| bryce | wgrant: well my hope is to try to keep the scope of what we do within reason | 07:31 |
| wgrant | Of course. | 07:32 |
| njh | ok, I've got it correctly matching the mouse | 07:35 |
| tjaalton | bryce: I was wondering, should we make it a policy that every change is in git, even the small ones. Then there would be no need to remove the Vcs-* stuff from control files like loïc did, and it would be more clear to the casual committer | 07:35 |
| wgrant | njh: What needed changing? | 07:35 |
| njh | <match key="info.product" string="Marble Mouse (4-button)"> | 07:35 |
| wgrant | Ah, so it's a different name. | 07:35 |
| njh | doesn't actually set the xinput props though | 07:35 |
| tjaalton | bryce: also, the mail address could probably be changed to ubuntu-x | 07:35 |
| njh | but lshal sets props being defined | 07:35 |
| wgrant | If hal sees them and the device has been replugged, X should see them too. | 07:36 |
| wgrant | But the xinput/hal names won't match. | 07:36 |
| bryce | tjaalton: to be honest, I find doing things in git to be a real hassle, and makes things take 2-3 times as long as they should | 07:36 |
| wgrant | I think the old xorg.conf names should die soon and hal should be able to tell the server to set XI props. | 07:36 |
| njh | hal does not need a restart | 07:37 |
| njh | ok | 07:37 |
| tjaalton | bryce: we should probably have a git BOF at UDS then :) | 07:37 |
| njh | I've been removing the spaces from the prop names | 07:37 |
| wgrant | bzr! | 07:37 |
| tjaalton | bzr can't do git | 07:37 |
| njh | is that bad? | 07:37 |
| wgrant | njh: xinput properties don't have the same names. You should use fdi files as if they were xorg.conf. | 07:38 |
| njh | oh | 07:38 |
| njh | I have no idea what the xorg names are | 07:38 |
| bryce | I'd be willing to give it a go with bzr | 07:38 |
| wgrant | njh: The names in the example look good. | 07:38 |
| wgrant | bzr makes sense, but the problem is that it's not trivial to keep pulling from git. | 07:38 |
| wgrant | Importing from git is easy, but not continously. | 07:39 |
| bryce | hm, I've tried doing merges through git a few times, but I found the procedure to be fairly intricate | 07:40 |
| tjaalton | having stuff in git.d.o allows the debian people to see what we do, and point out potential problems like jcristau does | 07:40 |
| bryce | for complex things like xserver, xorg, etc. that have a lot of patches and changes to merge, I can accept that it's worth the trouble, but with packages that have fewer changes it seems quicker just to do merges by hand | 07:40 |
| njh | wgrant, but they don't work :) | 07:41 |
| njh | so I can now effectively set hal attributes | 07:41 |
| njh | but I can't work out how to convince myself that X is listening to them | 07:41 |
| njh | bryce's diff trick is very helpful | 07:41 |
| njh | add that to your toolbox! | 07:41 |
| tjaalton | git fetch; git merge debian-unstable, that's not difficult | 07:41 |
| njh | I find git frustrating | 07:42 |
| njh | despite mental's badgering, I still find myself using svn | 07:42 |
| tjaalton | when your own tree is old, you need to git rebase origin/ubuntu first | 07:42 |
| tjaalton | there's at least one mesa change that is not in git yet | 07:42 |
| njh | I suspect it's just curmudgeonness | 07:42 |
| njh | it took me years to switch from cvs :) | 07:43 |
| njh | at least with git I can use both on the same project | 07:43 |
| wgrant | git doesn't seem to make sense. | 07:43 |
| wgrant | bzr is fine. | 07:43 |
| tjaalton | svn doesn't make sense :) | 07:43 |
| njh | it must | 07:43 |
| njh | it was written by god himself | 07:43 |
| tjaalton | well I find bzr confusing so here we go :) | 07:43 |
| njh | mental dislikes bzr | 07:44 |
| njh | nup | 07:45 |
| njh | those parameters are not being fed through to X | 07:45 |
| njh | they get as far as hal | 07:45 |
| bryce | njh, now that he works for canonical and will probably have to use it, it'll be interesting to see if his opinion evolves | 07:46 |
| njh | actually, he hates it _since_ he started using it at canonical | 07:46 |
| njh | on the other hand, he has seen the light wrt python :) | 07:46 |
| wgrant | Who are we talking about? | 07:46 |
| * njh smugly points out that bryce now uses apt and mental now uses python | 07:46 | |
| njh | wgrant, nobody knows... | 07:47 |
| bryce | wgrant: njh and mental are two of the guys that founded Inkscape with me | 07:47 |
| njh | he is known as.... | 07:47 |
| njh | ...mental | 07:47 |
| wgrant | Ahh. | 07:47 |
| njh | yes, the triumvirate: the maiden, the mother and the crone | 07:48 |
| njh | (we're still fighting over who is what) | 07:48 |
| bryce | njh: fwiw, I'm finally doing python too | 07:48 |
| njh | bryce, good to hear | 07:48 |
| njh | glad you've finally seen the light | 07:49 |
| wgrant | How can one not do Python? | 07:49 |
| njh | bryce and I used to argue about python vs perl | 07:49 |
| njh | so, does anyone else have evidence that setting parameters via fdi actually has any effect on xorg? | 07:50 |
| bryce | wouldn't go so far as seeing light... | 07:50 |
| njh | because I can make them anything, and nothing changes | 07:50 |
| wgrant | njh: Yes. I do it all the time. | 07:50 |
| njh | the data is coming from somewhere else | 07:50 |
| wgrant | njh: It depends on whether the driver is looking at them or not. | 07:50 |
| njh | so what is ZAxis? | 07:51 |
| njh | is it the same as YAxis? | 07:51 |
| njh | is there an XAxis? | 07:51 |
| njh | meh, I'm tired | 07:54 |
| njh | thanks for all your hel[ | 07:54 |
| njh | help | 07:54 |
| njh | at least I can trust hal works | 07:54 |
| njh | I just need to connect it to xorg | 07:54 |
| njh | however, unless you have evidence to the contrary, this page is wrong: | 07:55 |
| njh | https://help.ubuntu.com/community/Logitech_Marblemouse_USB | 07:55 |
| njh | perhaps you can ask if anyone has actually got it working | 07:55 |
| njh | looks like people are still having trouble anyway | 07:57 |
| wgrant | I've seen a few people on ubuntuforums use that fine,. | 07:57 |
| * njh reads more bugs | 07:57 | |
| njh | really? (does spoke eyebrow thing) | 07:57 |
| njh | or merely run away | 07:58 |
| njh | ok, bed time | 07:59 |
| njh | ttyl | 07:59 |
| tjaalton | mvo: hey, I've seen a lot of "failed to install/upgrade" errors due to "package foo is already installed and configured". what's causing that? | 09:03 |
| seb128 | I was going to ask that too ;-) | 09:06 |
| tjaalton | they are all over the place, so it's pretty common I guess.. | 09:08 |
| mvo | tjaalton: do you have a example bug number for me? | 09:08 |
| seb128 | mvo: bug #296576 | 09:09 |
| ubottu | Launchpad bug 296576 in eog "package eog 2.24.1-0ubuntu1 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/296576 | 09:09 |
| tjaalton | mvo: bug 296571 (just happened to look at ghostscript bugs) | 09:09 |
| ubottu | Launchpad bug 296571 in ghostscript "package ghostscript 8.63.dfsg.1-0ubuntu6 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/296571 | 09:09 |
| tjaalton | plenty of them against the x packages too | 09:09 |
| mvo | thanks, looking | 09:09 |
| tjaalton | seb128: heh, appears to be the same reporter | 09:11 |
| seb128 | he likely opened several duplicates | 09:11 |
| tjaalton | yep | 09:12 |
| bryce | heya mvo | 09:30 |
| bryce | <mvo> hm, so I read reports that compiz does hang on a i945 for intrepid --- lp#? | 09:31 |
| bryce | <mvo> tjaalton: is there someone familiar with intel I could talk to? do we have a contact at intel? I mean, blacklisting i830,845,945 does not leave that many cards that we don't blacklist | 09:31 |
| bryce | <mvo> bryce: ^--- ? | 09:31 |
| mvo | bryce: good monring | 09:32 |
| mvo | bryce: https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/296819 | 09:32 |
| ubottu | Launchpad bug 296819 in compiz "Intrepid Compiz hangs on login for i945GM video cards" [Undecided,Incomplete] | 09:32 |
| bryce | mvo: i830/i845 should be considered separate from i945 | 09:32 |
| mvo | bryce: it seems like it is ot affecting all i945 system so it is less servere | 09:32 |
| mvo | bryce: 830/845 are blacklisted now | 09:33 |
| mvo | but blacklisting i945 would blakclist half of the laptops out there (and all netbooks ;) | 09:33 |
| bryce | pre-855 is hardly supported by upstream any longer, so compiz issues on those chips are not terribly high priority (unfortunately IMHO, but seems reality) | 09:33 |
| bryce | i945 are more recent and more important | 09:33 |
| mvo | yes, I'm sad about the lack of <855 | 09:34 |
| bryce | from bug reports, I've seen huge variability in i945 | 09:36 |
| bryce | many issues are specific down to the subsystem vendor pci id | 09:36 |
| bryce | ...so if you blacklist, I'd just ask that you blacklist at the subsystem vendor pci id. (i.e., the second line from lspci -vvnn) | 09:41 |
| tjaalton | pitti had the same pci id and works fine | 09:41 |
| bryce | if two people with the same subsystem vendor pci id have the same problem, then one would have to conclude it's due to some difference other than video card chips. | 10:01 |
| bryce | anyway, night. | 10:01 |
| tjaalton | night | 10:01 |
| mvo | night | 10:01 |
| seb128 | mvo: did you look at this install bug? | 10:02 |
| mvo | seb128: no, was doing other stuff | 10:03 |
| mvo | not yet | 10:03 |
| seb128 | ok | 10:03 |
| superm1 | tseliot, not sure if you were aware yet: http://www.nvidia.com/object/linux_display_ia32_177.82.html | 17:52 |
| superm1 | it's a bug fix release | 17:52 |
| tseliot | superm1: no, I wasn't aware of that. Thanks | 17:52 |
| superm1 | tseliot, when they are saying mobile GPUs with suspend problem, it's most 9xxx mobile GPUs, and rather annoying :( | 17:53 |
| tseliot | superm1: ok, I'll request another SRU soon | 17:54 |
| superm1 | tseliot, if you need sponsorship to jaunty, let me know and i can upload it when you've got packaging ready | 17:55 |
| tseliot | ok ;) | 17:55 |
| superm1 | tseliot, or if you normally use PPA pocket copying, nvm | 17:55 |
| tseliot | I usually upload the source to my webspace | 17:56 |
| solarion | will there be any trouble if I buy a HDCP-aware monitor for use with Linux? | 20:17 |
| tjaalton | solarion: no | 20:26 |
| solarion | tjaalton: thanks. I waited and then asked xorg-devel. :) | 20:28 |
| tjaalton | yeah noticed that afterwards | 20:29 |
| solarion | :) | 20:30 |
| solarion | what'd you say are the most important things to consider in an lcd monitor? | 20:30 |
| solarion | screen size and res are obvious | 20:30 |
| tjaalton | dont buy the cheapest, and preferably with !TN panel | 20:39 |
| solarion | why not the cheapest? | 20:42 |
| tjaalton | there's a reason they are cheap | 20:44 |
| bryce | brightness is another consideration | 20:46 |
| bryce | although most lcd's these days are sufficiently bright | 20:46 |
| solarion | what's a good brightness? | 20:46 |
| bryce | just make sure it's got a broad range | 20:47 |
| solarion | tjaalton: I mean, is there usually a specific thing cheap lcd monitors are cheap because of, that's not immediately obvious to the novice? | 20:48 |
| tjaalton | missing digital input(s), TN panels, bad ergonomics etc | 20:49 |
| solarion | what digital inputs would be missing? | 20:49 |
| tjaalton | dvi for instance | 20:50 |
| solarion | aside from DVI and VGA, what other connectors do you think are important (HDMI is irrelevant to me, I think) | 20:51 |
| tjaalton | mine has a usb-hub in it which is handy | 20:54 |
| * solarion ponders | 20:55 | |
| solarion | what is better than a TN panel? | 21:06 |
| tjaalton | IPS/*VA | 21:09 |
| tjaalton | eizos are MVA's I think.. | 21:09 |
| solarion | why is tn bad? | 21:33 |
| tjaalton | the viewing angle and gamut coverage is narrower | 21:48 |
| solarion | ah | 21:48 |
| solarion | what's the going price for a good lcd? | 21:49 |
| tjaalton | but just buy what pleases your eyes and budget :) | 21:49 |
| solarion | I can buy a second card and 3 monitors for under $600. :) | 21:49 |
| solarion | good resolution too | 21:49 |
| tjaalton | my 24" benq cost around 800EUR, and it's pretty good | 21:50 |
| solarion | ouch | 21:50 |
| solarion | that's probably more than the bosses would let me have. :) | 21:50 |
| tjaalton | yes, you can do a lot of stuff for $600 ;) | 21:50 |
| tjaalton | hm s/do/get/ | 21:52 |
| solarion | both work. :) | 21:54 |
| solarion | thanks for the info | 21:54 |
| solarion | maybe when I'm a professor I can get a real LCD. | 21:54 |
| tjaalton | heh, and some time I'll get an eizo for photo management :) | 21:55 |
| tjaalton | wow, 24" review champ eizo for 500EUR | 21:58 |
| festr_ | hi | 22:00 |
| festr_ | i'm trying to test GEM with 2.6.28-rc4 and xorg/mesa/intel master branches. I'm getting in xorg log (II) AIGLX: Screen 0 is not DRI2 capable | 22:01 |
| festr_ | but 3d works. so i'm wondering this DRI2 issue. any idea? | 22:01 |
| tjaalton | don't think anyone here has gone that far | 22:02 |
| tjaalton | besides it's not the master branches you want | 22:02 |
| festr_ | i'm not able to find any info how to check if GEM is actually used if you understand :) | 22:02 |
| jcristau | there's no dri2 support in intel ddx master | 22:02 |
| jcristau | so that's expected | 22:02 |
| festr_ | so thats explain it. exist some dri2 branch is it worth of try? | 22:03 |
| jcristau | i don't think it's worth it at this point | 22:04 |
| festr_ | i though that new 2.5.0 with gem and uxa has dri2 | 22:06 |
| === superm1` is now known as superm1 | ||
| jcristau | nope | 22:15 |
| === philwyett_ is now known as philwyett | ||
| bryce | tjaalton: regarding bug 278318, I've updated the patch to flip it such that texturedvideo is true by default. I'll post a debdiff. | 22:42 |
| ubottu | Launchpad bug 278318 in xserver-xorg-video-intel "video tearing with textured video on intel card" [High,Triaged] https://launchpad.net/bugs/278318 | 22:42 |
| bryce | tjaalton: posted. If people wish for something more elaborate than just that, then I think we should leave it to jaunty and skip doing an sru. | 22:48 |
| bryce | restoring an xorg.conf option seems pretty low risk, but mucking about in the video driver logic is probably better to leave for the development branch. | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!