[13:25] <tomreyn> hi there. i'm having an issue, possibly with xorg-edgers's modules / mesa. it only affects a single steam game, though, which is admittedly weird.
[13:27] <tomreyn> i rebooted this system (actually power off/on) after roughly two weeks of uptime + installed updates. ever since then, mouse and keyboard input is registered with much delay by this 3d MOBA game (called 'Strife', by S2 games).
[13:28] <tomreyn> neither steam nor this game way updated during these two weeks (or after the reboot).
[13:28] <tomreyn> s/way/was/
[13:28] <tomreyn> nor was steams / this games' configuration changed.
[13:29] <tomreyn> other 3D games do not show this behavior, however.
[13:31] <tomreyn> the delay is massive, often taking up to 3-5 seconds (while other times there is no delay at all). it is as if mouse + keyboard input is cached and the cache not checked frequently enough.
[13:31] <tomreyn> i'll be happy to try and help debugging this further if it seems worth it (but i would understand if not so, since i'm a single user reporting it for a single game only).
[13:32] <tomreyn> i'm on xubuntu 16.04 (fully patched),  AMD RV730 (DRM 2.43.0 / 4.4.0-51-generic, LLVM 3.9.0)
[13:33] <tomreyn> x86_64
[13:34] <tomreyn> i don't dare filing a bug report since i'm not even sure it's worth your time looking into this.
[13:34] <tomreyn> (but do tell me if i should)
[14:05] <jcastro> hey tjaalton, do you know if the new rolling HWE thing will also cover mesa?
[14:18] <tjaalton> jcastro: normally it would
[14:19] <tjaalton> it just replaces lts-yakkety/lts-zesty/lts-?? with lts-hwe
[14:19] <jcastro> tjaalton: right so what I was thinking, given the announcement, that the point releases with the HWE kernels would help fix the old mesa problem in distro itself
[14:20] <tjaalton> jcastro: to some extent yes, and we've had that for two lts releases now
[14:20] <tjaalton> and third still tbd what it looks like
[14:20] <tjaalton> yakkety shipped with 12.0.3, not 13.0.x
[14:21] <tjaalton> which is what feral "needs"
[14:21] <jcastro> well, tbh I don't think anyone needed mesa to be so aggressively updated until the past year or so right? 
[14:21] <jcastro> not sure, I don't have AMD gear
[14:22] <tjaalton> right, amd finally ditched fglrx
[14:22] <tjaalton> which puts more pressure on mesa
[14:23] <jcastro> but, theoretically if the guy pushing aggresively in the PPA's work can be reused in whatever is in -devel and normal releases then maybe the normal releases won't be as behind as much?
[14:23] <tjaalton> normal releases are still bound to FF
[14:24] <tjaalton> and upstream release schedule doesn't necessarily align with outs
[14:24] <tjaalton> ours
[14:24]  * jcastro nods
[14:24] <tjaalton> mesa 13 got delayed
[14:24] <tjaalton> partly because 12 got delayed
[14:24] <jcastro> well, I suspect any gamer or enthusiast will just use the PPA and deal with it since that's probably way better for them than the old fglrx days
[14:24] <tjaalton> I kept asking when 13 is released since august, but didn't get a reply until it was too late
[14:24] <tjaalton> yes
[14:25] <tjaalton> HWE wise the latest isn't always needed
[14:25] <tjaalton> and support for new hw can be backported fairly easy
[14:26] <tjaalton> I have a package with polaris support (from 12) added on top of 11.2
[14:28] <jcastro> does debian use the same exact packaging? like, do we both build out of that git repo?
[14:28] <tjaalton> still, would rather see 12 backported as-is, unrenamed. then after 1704 is released the same for mesa 2017.03 or whatever
[14:28] <tjaalton> yes
[14:28] <jcastro> so, if we get those two PPA building guys to just do their work their, it fixes both distros and the PPA. :D
[14:28] <tjaalton> yes
[14:29] <tjaalton> they'd need to be on irc and on pkg-xorg
[14:29] <jcastro> ack
[14:29] <tjaalton> preferably #debian-x@ofc too
[14:29] <tjaalton> oftc
[14:29] <jcastro> ok
[14:30] <jcastro> I'll recommend that as a next step
[14:30] <tjaalton> git snapshots don't need to be kept on a proper branch, but once a rc is released it's usually kept on the debian-experimental branch and packaging fixed there
[14:30] <tjaalton> then once the new release has it's first or second point-release, it's moved to debian-unstable
[14:31] <tjaalton> or merged there actually
[14:31] <tjaalton> with every new upstream release there is a certain git dance that needs to be handled so that the history remains intact
[14:31] <tjaalton> the old upstream needs to be merged with 'git merge -s ours'
[14:31] <mamarley> tseliot: Sorry, I forgot to test 304 yesterday.  I will do that today.  Also, don't hesitate to bug me about these things. :)
[14:32] <tjaalton> then the packaging branch
[14:32] <tjaalton> anyway, I can teach them when the time is right
[15:10] <tseliot> mamarley: ok, I'll wait for your results. Thanks