[00:00] <RAOF> Yup.
[00:00] <cnd> hmm, ok, that will help with xorg-gtest
[00:00] <cnd> though we still have to do gtest.m4 since gtest doesn't ship a pkgconfig
[00:00] <RAOF> Right.
[00:04] <cnd> RAOF, do you know if there's any standard name for a source dir in a pkgconfig file?
[00:05] <RAOF> I don't think so.
[00:05] <cnd> I'm using sourcedir
[00:07] <RAOF> Sounds reasonable.
[00:07] <cnd> RAOF, how do you get the variables out of a pkgconfig file?
[00:07] <cnd> PKG_CHECK_MODULES only does CFLAGS and LIBS
[00:07] <cnd> IIUC
[00:07] <RAOF> pkg-config --variable=$VARIABLE $PACKAGE
[00:07] <cnd> ok
[00:08] <cnd> so you have to do it a bit manually
[00:08] <RAOF> So you'll be doing something like ‘XORG_GTEST_SRC_DIR = $(shell $(PKG_CONFIG) --variable=sourcedir xorg-gtest)
[00:08] <RAOF> Yeah, a little manually.
[00:08] <RAOF> You can hide it behind your m4 macro, though.
[00:11] <cnd> yeah
[00:48] <eruditehermit> sforshee, hey are you about?
[14:51] <sforshee> cnd, I just took a look at the bug that I think was filed by eruditehermit (bug 950496). From playing back the evemu-record capture everything looks normal. I updated the bug; if there's any other useful information he could supply please add a comment.
[14:51] <sforshee> cnd, that should be bug 950469
[14:51] <cnd> sforshee, interesting
[14:51] <cnd> thanks
[14:52] <cnd> though if it worked for you, I'm not real sure what could be wrong
[14:55] <sforshee> cnd, the first time I played it back it was from on my desktop and the pointer started moving all over the place :)
[14:55] <sforshee> I'll know better than to do that again
[14:56] <cnd> heh
[17:20] <apw> bryceh, about?  am looking for a relativly safe (perhaps quite low resolution) edid for some testing, as in the binary data for one
[17:22] <apw> bryceh, as i believe they have checksums right ?
[18:32] <bryceh> apw, heya
[18:32] <apw> bryceh, hey, i sent you an email on the edid thing
[18:32] <bryceh> apw, just read it -- awesome!!
[18:32] <apw> cool
[18:32] <bryceh> apw, sure I can dig up edids for you
[18:32] <apw> bryceh, i probabally don't need it now, i used my existing one
[18:33] <apw> bryceh, which i deliberatly corrupted in the text fields
[18:33] <bryceh> apw, ah ok.
[18:34] <apw> bryceh, then loading it, triggered a checksum warning so i think it worked at least at a basic level
[18:35] <bryceh> apw, if I have time today I'll bang on it a bit myself
[18:35] <apw> bryceh, i am hoping you'll be able to load a low res edid into something and show it restricts resolution or something
[18:35]  * apw only has a 1024x600 display here with him, rather annoyingly
[18:38] <bryceh> apw, would be awesome if we could get this in for P, but I agree given the late date it might be safer to leave to Q.  What more would need done to get it into the P kernel?
[18:39] <apw> bryceh, i am sure the patch is not yet 'ready' pretty sure it leaks memory, but overall its pretty safe looking, so i think with some twiddling we could get it up to scratch (assuming you find value in it)
[18:39] <apw> bryceh, and i think if you find value in it we can get it in
[18:39] <bryceh> ok
[18:40] <apw> bryceh, as it is pretty benign if its not used
[18:40]  * bryceh nods
[18:40] <bryceh> as it happens there is an active bug right now I've been looking at, where the user's monitor is providing crap edid
[18:42] <bryceh> apw, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/927155
[18:44] <apw> bryceh, yeah if it "fixes" that sort of thing, then its even easier to justify it as effectivly a bug fix
[18:44] <bryceh> exactly
[18:45] <bryceh> I can definitely scare up a few such bugs.
[18:45] <bryceh> I probably also have a kvm or two here that truncates edid, which this will fix.
[18:46] <Sarvatt> oh man, Viewsonic VA2012w
[18:46] <Sarvatt> i had that same monitor and the EDID got killed on it too
[18:48] <apw> Sarvatt, as in the thing just decided to forget its own edid ?
[18:48] <apw> bryceh, is that popey on that bug?
[18:48] <bryceh> apw, yup
[18:50] <Sarvatt> apw: yeah, there was a problem where the edid would get corrupted when using them on nvidia gpu's with some  buggy windows drivers
[18:51] <apw> Sarvatt, the mind boggles, i'd expect them to be r/o in hw
[18:52] <Sarvatt> you can rewrite those viewsonic ones from that era, i remember having to do that a bunch of times
[18:55] <apw> bryceh, RAOF, while i remember, once you have put an edid in there it is pinned, you echo an empty line into there to let it be replaced by the real edid again
[19:03] <apw> bryceh, ok i think its actually not leaking there is some background blob management
[19:03] <apw> bryceh, i think it should be adding edid/ on the firmware filename though for safety, other than that its prolly close
[19:05] <bryceh> apw, ok.  got it loaded on a system.  
[19:08] <apw> bryceh, although it easy to see how one could automatically fix broken edids with this, letting udev check bad ones and replace them, its not clear how the 'all 0xff' case can be fixed
[19:10] <bryceh> yeah.  probably still would require some manual user action
[19:12] <Sarvatt> ah hah finally found the magic that fixed my old viewsonic,  Power up the monitor connected to the VGA and DVI outs both. Once fully powered up, power the machine back down, disconnect the monitor from the power outlet for ~30 seconds, and boot up with only the DVI input connected.
[19:12] <bryceh> Sarvatt, I also found an edid.exe on the viewsonic site
[19:12] <Sarvatt> this was like 5 years ago so memory was fuzzy, that really reset the edid on my viewsonic
[19:12] <apw> bryceh, anyhow, having reviewed it i am happier its something we can accept, if your testing is good, i'll work on getting the prefix added for next week
[19:12] <bryceh> no directions on how to use it though.
[19:13] <bryceh> apw, excellent.  I'll plan on banging on it in the meantime.
[19:21] <apw> bryceh, only three cycles ... sigh
[19:23] <apw> Sarvatt, that is some arcane magic indeed
[19:25] <Sarvatt> apw: yeah asked him to try it, those viewsonics from around 2006 when they first started doing the 20" widescreens were so crappy
[19:25] <Sarvatt> google viewsonic bad edid
[19:25] <Sarvatt> its full of fun
[19:26] <apw> bryceh, it'd would be good to know if get-edid can get the edid when the kernel bit bashing cannot... i guess in the short term udev could use that to fill it in :/
[19:26] <apw> bryceh, allllll assuming the edid is useful once you've 'rit it in your testing
[19:28] <bryceh> right
[19:29] <apw> and did it, did it, did it?  /me needs to drink less coffee
[19:29] <bryceh> yeah I've been finding get-edid isn't super reliable.  Maybe only 10-25% of the time do we get something worthwhile
[19:29] <bryceh> sorry, got called away to breakfast
[19:30] <apw> heh, i am just starting on the G&Ts so i'll stop making sense shortly
[19:31] <bryceh> well deserved!
[19:31]  * Sarvatt is jealous
[19:32] <apw> yeah its been one of those weeks, though my not wanting to work has gotten me on these 'small' tasks which got you your edid kernel ...
[19:32] <apw> and leann about 4 wi's closed ...
[19:34] <bryceh> ok, why am I not finding the edid file
[19:35] <bryceh> ok, it's there on an -ati system but not an -nvidia??
[19:35] <bryceh> find /sys/devices -name edid gives nothing there.  weird
[19:36] <bryceh> moving on... intel next
[19:45] <apw> bryceh, oh, only tested it only intel myself, but it comes from common code
[19:46] <apw> bryceh, so i would expect them all to express one
[19:47] <bryceh> yeah nfi with the nvidia box.  I'll have to investigate that more
[19:47] <apw> /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/edid
[19:47] <apw> bryceh, binary drivers by accident perhaps
[19:47] <bryceh> could be
[19:48] <bryceh> well, I mean it definitely has a binary driver loaded.  could be it just doesn't provide edid.  I'll try with nouveau
[19:48] <apw> didn't the installer get changed back in 'o' or something to install them by default
[19:48] <apw> doesn't the nvidia binary driver supply its own way to futsz with the edid ...
[19:52] <Sarvatt> yea or at least it did at one point
[19:52] <apw> bryceh, so .... the ultimate question, does it work
[19:53] <cnd> RAOF, if you want a MIR for gtest without shipping the precompiled libs, then we'll have to do a FF exception to get the latest xorg-gtest in
[19:54] <cnd> after I get stuff reviewed and merged on #xorg-devel
[19:59] <bryceh> apw, well...  the edid file is empty (but get-edid is able to read it)
[20:06] <mlankhorst> noon
[20:06] <bryceh> heya mlankhorst 
[20:11] <mlankhorst> hi :)
[20:22] <bryceh> apw, ok so copying in edids seems to work ok, except on the nvidia system where it doesn't work even if -nvidia is uninstalled.
[20:23] <bryceh> apw, and on one system I get the proper resolutions, so it hasn't broken it.  I'm not 100% certain the written edid is overwriting the old though.
[20:24] <bryceh> apw, third system is unable to detect the proper resolutions across the kvm, so is a great candidate for testing the fix.  However, so far the edid doesn't appear to take effect, I just get vesa modes.
[20:24] <bryceh> in all cases I'm using edid gathered from get-edid and assuming that's a valid blob
[20:25] <apw> bryceh, cirtainly when i hexedit'd the one i had, it started saying there was an edid checksum erorr
[20:25] <bryceh> apw, so, I think I can give a light confirmation that it works so far.  I'll play with it more next week to get a stronger confirmation.
[20:26] <apw> bryceh, sounds good.  i am done now for the week anyhow, lets catch up monday
[20:27] <bryceh> sounds good
[21:15] <cnd> bryceh, whot has picked up the clickpad patches and has an attempt at fixing the clickaction vs clickpad issue
[21:16] <cnd> he wants to merge it all for this release of synaptics
[21:16] <bryceh> ok
[21:16] <cnd> if that happens, we will probably want to go with upstream
[21:16] <cnd> but that means re-enabling the clickpad stuff, but hopefully in a better working form
[21:16] <cnd> should I propose an FFe for it?
[21:17] <cnd> or reopen the first FFe?
[21:17] <cnd> or?
[21:17] <bryceh> either way, reopen the first one if that'd save you some time
[21:18] <cnd> ok
[21:21] <Sarvatt> the first FFe got approved, maybe thats good enough? :P
[21:23] <cnd> yeah, I was wondering the same, but one factor in an FFe approval is timin
[21:23] <cnd> timing*
[21:23] <cnd> so I think we can't rely on the earlier approval
[22:14] <eruditehermit> sforshee, hey
[22:14] <sforshee> eruditehermit, hi
[22:15] <eruditehermit> sforshee, so my kernel driver is working but my mouse isn't moving?
[22:15] <sforshee> eruditehermit, that's how it looks to me. In fact, I played back your capture and watched my pointer move :)
[22:15] <eruditehermit> lol
[22:16] <eruditehermit> sforshee, any ideas why?
[22:17] <sforshee> eruditehermit, not yet. X seems to see your touchpad, so I don't know what's happening.
[22:17] <sforshee> apport-collect didn't attach the xorg log though
[22:18] <sforshee> can you attach /var/log/Xorg.0.log from a session when the mouse doesn't work?
[22:18] <eruditehermit> http://paste.ubuntu.com/
[22:18] <sforshee> and if cnd has any ideas of what to look at, I'm all ears
[22:18] <eruditehermit> err
[22:19] <eruditehermit> http://paste.ubuntu.com/876687/
[22:19] <eruditehermit> so I have sections where my mouse was proto=any
[22:19] <eruditehermit> and sections where it was proto=exps
[22:19] <eruditehermit> its really hard to give you a completley clean log
[22:19] <eruditehermit> since I need my mouse!
[22:19] <eruditehermit> lol
[22:20] <eruditehermit> can't pastebin stuff without it
[22:20] <eruditehermit> lol
[22:20] <cnd> sforshee, are any evdev device properties set for alps trackpads?
[22:20] <sforshee> Using input driver 'evdev' for 'ImPS/2 Generic Wheel Mouse'
[22:20] <cnd> evdev properties aren't captured by evemu yet
[22:20] <sforshee> this is when the mouse isn't working?
[22:21] <sforshee> eruditehermit, ^
[22:21] <cnd> sforshee, I bet that's when it is working
[22:21] <sforshee> that's what I think
[22:21] <eruditehermit> that is when it is working
[22:21] <eruditehermit> ok
[22:21] <eruditehermit> tell you what
[22:21] <eruditehermit> I'll reboot
[22:21] <eruditehermit> with the mouse not working
[22:22] <eruditehermit> VT switch
[22:22] <eruditehermit> cp log
[22:22] <eruditehermit> then reboot again
[22:22] <eruditehermit> brb
[22:36] <eruditehermit> sforshee, cnd: http://paste.ubuntu.com/876712/
[22:37] <sforshee> cnd, why would X not be using the synaptics driver?
[22:40] <Sarvatt> eruditehermit: umm, xorg-edgers, might be broken
[22:40] <Sarvatt> is xserver-xorg-input-synaptics installed?
[22:40] <cnd> eruditehermit, you're using xorg-edgers?
[22:40] <Sarvatt> i've been too focused on precise to keep up with edgers lately
[22:41] <Sarvatt> hmm xserver-xorg-input-evdev in edgers doesn't work right now too from the looks of it
[22:41] <Sarvatt> since it thinks the input abis are the same
[22:42] <eruditehermit> ah
[22:42] <eruditehermit> I forgot about edgers
[22:42] <eruditehermit> let  me ppa-purge
[22:43] <Sarvatt> ppa-purge wont work because you're on x86_64, will take a lot of manual downgrades :(
[22:43] <eruditehermit> wait what?
[22:44] <eruditehermit> :(
[22:44] <eruditehermit> brb
[22:46] <Sarvatt> i'm just gonna upload upstream evdev and synaptics driver updates, too many friggin patches to fix and check for this late on friday night :)
[22:46] <Sarvatt> (to use ubuntu branches)
[22:49] <eruditehermit> disregard bug
[22:49] <eruditehermit> I'm stupid
[22:49] <eruditehermit> =p
[22:49] <eruditehermit> xorg-edgers
[22:50] <cnd> eruditehermit, I'm glad we figured it out :)
[22:50] <cnd> thanks!
[22:50] <cnd> be sure to move the bug to invalid if you haven't already
[22:50] <eruditehermit> I will
[22:50] <eruditehermit> also
[22:51] <eruditehermit> it seems the pointer acceleration and sensitivity can't be set via gnome
[22:51] <eruditehermit> is that known?
[22:53] <Sarvatt> eruditehermit: really sorry about that, didn't realize edgers was broken because i stopped using it for the past few weeks to test precise stuff, uploaded new checkouts now though
[22:55] <Sarvatt> i'm waiting for mesa to settle the heck down wrt the autoconf changes on master before going back to it, redoing the packaging every other day gets old when there isnt enough time in a day as it is :)
[22:56] <sforshee> cnd, what do the the acceleration and sensitivity sliders actually change? Is it something that trickles down to the kernel driver?
[22:56] <Sarvatt> eruditehermit: which ones, the ones in the mouse or the touchpad tab?
[22:56] <cnd> sforshee, I think gnome is broken
[22:57] <cnd> it doesn't do anything for me either
[22:57] <cnd> but I've never taken the time to look into it
[22:57] <sforshee> cnd, the acceleration one seems to make a difference on the macbook air at least
[22:57] <cnd> it doesn't work for my magic mouse
[22:57] <cnd> it may work for synaptics but not evdev?
[22:58] <sforshee> when alps is working correctly it's using synaptics
[22:59] <cnd> yeah
[22:59] <cnd> maybe eruditehermit was seeing the issue while he was using evdev?
[22:59]  * sforshee boots up his crappy old dell to see what happens
[23:03] <eruditehermit> Sarvatt, the ones in mouse
[23:04] <cnd> those would be the ones for evdev then
[23:05] <cnd> eruditehermit, please file a bug for that and paste it here
[23:05] <cnd> I can mark it as a bug that needs to be looked at by beta 2
[23:06] <eruditehermit> cnd, err I've got to run now
[23:06] <eruditehermit> cnd, will be back later
[23:07] <cnd> ok
[23:07] <eruditehermit> I need to understand what to file so I will ask questions
[23:07] <cnd> sure
[23:07] <eruditehermit> bbl
[23:07] <eruditehermit> thanks for all the help!
[23:07] <sforshee> eruditehermit, the acceleration slider seems to have an effect on this dell with an alps touchpad
[23:08] <sforshee> i still have no idea what the sensitivity slider is supposed to be changing
[23:10] <Sarvatt> eruditehermit: really though, is xserver-xorg-input-synaptics installed? it doesn't look like it is from your log
[23:10] <Sarvatt> AlpsPS/2 means its in synaptics mode and should be using -synaptics
[23:10] <Sarvatt> its ImPS/2 when its in the old mode that needs evdev
[23:11] <cnd> sforshee, eruditehermit was referring to the slider in the mouse tab
[23:11] <cnd> I think :)
[23:12] <sforshee> cnd, that would explain it :)
[23:12] <Sarvatt> also acpi_osi=Linuxi is a typo
[23:13]  * sforshee -> EOW, have a good weekend everyone
[23:19] <mlankhorst> Sarvatt: generally just want to mimmick windows..
[23:52] <Sarvatt> sforshee: dont suppose you know any magic to fix DFS on wl? :P brcmsmac is so horrible