Gfx corruption and mouse issue? I get that. I am using nvidia (latest beta DRV) and use cinnamon (latest but effects disabled) I did however launch via steam rather than ./PA. I'll try again later
A quick update.. Tweaked the vsync options - rebooted & tried again - nothing else running apart from the desktop & PA. Game started and didn't appear to have flickering - but screen updated only if I moved the mouse out of the PA window. So - Hit Accept on the License, nothing changes, mouse out of the PA window, screen is updated and the main screen is displayed. Mouse in & click the password box - type password and don't see the password char markers - move the mouse out of the PA window and the password field now shows markers. Combined with earlier it appears the flickering is happening - but it's just faster so not leaving visual artefacts - but the net result is the same. Appears to be sync/paint related.
I can't seem to find a post where you wrote if you do, or if you don't have compositing/effect enabled
Compositing is enabled. Attached the xorg log here and to the bug report. I'm futzing around with the CCC settings to see if something helps with it - but I'm not a huge fan of it - you never know what else it changes. I just noticed in the PA log some errors that are probably related:
So try to disable those desktop effects/compositing or install a normal window manager, who let's you disable desktop effects. I'm 70 percent sure that the problem lies here. [rant] 5 frikin' years ago we had to battle same problems... After 5 years we can atleast disable desktop effects for fullscreen applications. [/rant]
That corruption issue is quite interesting. I had corruption going on for about a year now on my laptop, but it's not limited to PA. I have only 128MB video RAM, so if there is an error in the memory management, it is much more likely to hit me since memory regions will overlap more often if memory management isn't done properly. Until now I thought that the corruption was limited to my graphics card (X1400M) only, but now it appears more like ALL GPUs are affected, both Nvidia and AMD and Intel. It's just that you won't notice unless using composition AND running enough applications in parallel which all use a fair amount of textures. As soon as you are running enough applications so your video RAM gets evicted, the corruption kicks in. Now we need to find out whether this is limited to systems which use the Mesa stack, or if it also occurs with the proprietary drivers, though I doubt that. If it only occurs with open source drivers, then this means that there is a HUGE bug in Mesa. Please also start looking if there are reported issues which could confirm / explain the corruption issue: https://bugs.freedesktop.org/buglist.cg ... _id=313733 The corruption issue is still present in current git version of Mesa. I can assure that the corruption issue was not present yet 2 years ago.
umm - I'll give it a go but the problem only happened with the latest version - the previous versions didn't have the problem. After futzing around with settings in CCC - I can reduce the problem by turning off "Wait for vertical refresh" - which appears to stop the flickering and allows the screen to update without moving the mouse out of the PA window. Which kinda links it back to the sync and iirc sync was recently something tweaked in PA. A side effect of this setting via CCC is that the area around the mouse (approx 2-3x the mouse pointer height & width) carries over whatever was around the mouse when it entered the PA window. Nothing else has changed on the system - which indicates the problem is with changes in this specific build. Aye - as you mentioned the WM are kinda flaky but they've come a long way - we're finally at a stage where you can swap 'em out more easily without bringing X to its knees. I'm more irked by the direction being taken by most OS's to turn the desktop into a mobile UI. I understand the desire for common UI patterns across form-factors - but imho they're going the wrong approach by reducing them all to the lowest common denominator.
I'm using the proprietary drivers. I applaud the foss efforts but I don't think the community is in the right head-space to do it properly. There's way too much fragmentation, to much member-measurement - which prevents people contributing to existing or good projects. And currently Gnome and Canonical are too busy banging heads to actually be effective. I tend to stress my gpu fairly heavily. I run & develop crypto workers on my workstation 24/7 - at 50% load during working hours and before this build it would run happily at 30fps while the workers were running. Suspecting that PA isn't releasing the GPU properly in some situations is partly due to how these workers run - they sometimes have the same issue when I'm testing code. You start to get errors loading kernels on the gpu which indicate that a handle wasn't cleanly dropped. As retrry mentioned - I'll try disabling compositing and see what happens.
I have the issue (posted the video): nvidia-settings: version 310.14 (buildd@komainu) Tue May 28 07:05:53 UTC 2013
Nice to see devs that care about doing it right. I imagine you're planning to use a authserver-generated random token for autologin in the future?
Well Im on 319.23, I wonder if there is an issue with the beta drivers then I just played another test game and Isee full steam integration (finally my steam updated ). While i didn't experience any gfx corruption per say I did experience flickering cursor AND loss of cursor. Interesting enough I actually used ffmpeg to record (26% uploaded to YT) it and lo and behold the cursor is visible on the video & non flickering. This would imply it isn't being rendered simply on x11 otherwise: ffmpeg -f x11grab would see the same effect. Eqyually since PA, while windowed actually draws over my taskbar so I can't use my "start" equally affirms where PA is being drawn is incorrect.
Aye - how visible it is appears to be linked to the GPU config for "Wait for Refresh". On my AMD gpu - with it Off or "Off unless App specifies" - flickering is visible while the mouse is on the screen and over one of the window elements (like the License panel or the Left Menu on the home screen).
http://youtu.be/DFCYen2eJxw thats the vid, as you can see the cursor is actually visible. NOTE the terminal error interesting it started off with blinking cursor (at game creation), then invis (starting point selection & 1st few build) to blinking - again this isn't actually visible in the video (again note that while the curor is then visible to x11 layer, something is drawing above it)
Build 49900 Same issues with flicking as the last build here. Screen doesn't update unless you move the mouse out of the PA game window and then back in again. Wait for Refresh on AMD 13.4 Drivers set to "Off, unless App Specifies". Seeing a knock on effect when the game flickers in other windows - SMPlayer (an MPlayer wrapper) flickers as it did in the last build. Makes the game pretty unplayable :/
Only had this issue with recent versions, previous versions worked fine no display glitches. I'm running LXDE on Archlinux have no deskop compositing no nothing interfering with opengl or display acceleration. Enabling tear free desktop helps a little in AMD drivers 13.4 but the mouse and keyboard aren't very responsive either.
On version .4900 running on my mac (late 2011 macbook pro 15 inch) through steam the game is unplayable. Joining a game is fine, but when the game starting screen shows up, soon after, my laptop is very slow and on Activity Monitor it shows PA is using 300% CPU and not responding, yet it shows my cpu usage is at slightly over 50% and RAM usage is at 5.28 GB used out of 8GB total
Confirming the cursor problem, it's only visible (though blinking) while moving. I played before and it was ok. Installed Debian Jessie amd64 and NV driver 319.23, it freezed the first day, then updated the kernel to 3.9-1 (unstable) and since then it works; we'll see if it has really helped.
OK so that is at least 2 ppl with the nvidia 319 driver with this and one with 313 without. I wonder if there is a regression with 319 or a fix from 313 wet to compliance
I doubt it has something to do with the driver. I had the same version before when everything was fine.
