spartan: hi
spartan: hi
spartan: can anybody help i have radeon 9600 an trying to get tvout to work under debian
spartan: xorg ati drivers cant get the screen in native resolution 1280x1024 and cant get tvout to work
spartan: i tried to install fglrx but fglrx module wont load at all
arekm: try ati driver from git repository
spartan: tvout should wokr? i dont care about 3d acceleration and fancy stuff. I just need tvout (i mainly use this machine for watching movies)
spartan: arekm git is experimental?
arekm: git is bleeding edge
spartan: arekm it very wierd but atitvout wont work
spartan: and if i put s-video in tv from boot of system i get flickering on tv when x starts
arekm: with ati git driver?
spartan: will try git now just a sec
spartan: ok i got it now i just put ati insted of vesa in xorg.conf and restart xorg right?
spartan: hi
spartan: i got git xserver-xorg-video-ati
spartan: and i still get 1024x768 resolution max
spartan: arekm i tryied it wont work with ati driver from git it works but only in 1024x768 i dont understand why fglrx module wont load
arekm: spartan: from what I know tv out is limited to 800x600 anyway (in hardware)
arekm: spartan: for fglrx see topic
spartan: i did depmode and looks like agpgart was not compiled in kernel of course fglrx didnt work haha
icewaterman: maybe the topic is not clear enough, perhaps changing the order will help
icewaterman: like "fglrx users try #ati instead - support and development for open-source ATI driver"
icewaterman: hm, that doesnt sound well
icewaterman: just keep it as it is then :)
ghepeu: Hi. I was checking the git log and I've seen a commit with some performance numbers (pre: 150000 glyphs/sec, post: 185000 glyphs/sec)
ghepeu: I see that airlied is not here, but maybe he'll read a log. care to tell how you obtained those numbers (card, settings)?
ajax: ghepeu: probably from one of the x11perf tests
glisse: ghepeu: log from intel driver ?
ghepeu: no, commit is "r300: don't bother with VAP/TCL for render."
glisse: oh
ghepeu: I was curious because here I get only ~22000 char/s with render accel and exa
ghepeu: -aa10text
ghepeu: -a10text doesn't make sense, because afaik it doesn't use hw accel
glisse: ghepeu: Dave is a lucky kid he got lastest computer toys with high cpu & gpu ;)
glisse: s/high/high end
ghepeu: that's why I was asking :)
ghepeu: i did some profiling with sysprof and the most time consuming functions were markoffscreendirty (or something similar) and movepixmaps (or something similar)
ghepeu: that apparently shouldn't be directly releated to the hw performances but more to exa architecture
ghepeu: at least with discrete cards with on board memory
glisse: ghepeu: wild guess, can't remember intel exa accel history, is that to properly improve this bottleneck you need a memory manager
glisse: s/improve/fix
ghepeu: yeah, I thought that my problem was a common problem, but then airlied gets ~9x char/s
ghepeu: and my computer is not so old
agd5f: ghepeu: daves commit just reduces the 3D state that has to be set up for each prepare operation
ghepeu: my question was more "why your baseline is 9x my baseline?"
glisse: agd5f: btw shuffling cmd for instance to reusse same prog without flush should be a big win especialy for tex
ghepeu: "how exactly did you got those numbers?" that is "are we testing the same thing?"
glisse: ghepeu: because is computer is 9x times better :)
ghepeu: 9x times better than an athlon64 3500+?
agd5f: glisse: yes. I think we can move all the vap code to the init3D() function
glisse: agd5f: well i was thinking to fragprog too
glisse: agd5f: but i think this should be done in server
agd5f: glisse: true
glisse: so server organize rendering operation with same composition operation
agd5f: we could probably hack it in to the driver with some minimal flags
glisse: this could benefit other drivers too
agd5f: but server would be better
MrCooper: the server wouldn't really know which operations require the same or different shaders, would it?
glisse: then its easier in the driver to optimize state emission if you know that server will try to group together operation of same kind
MrCooper: BTW, it should be fairly straightforward to mostly remove ExaMarkOffscreenUsed overhead
glisse: MrCooper: i was thinking to just group together operation of same type but different source
agd5f: the main difference is mask vs. no mask
MrCooper: glisse: not sure that's feasible, certainly not in EXA
agd5f: MrCooper: what would be needed?
agd5f: to remove the overhead
MrCooper: agd5f: to make it not so horribly stupid :)
glisse: well i am not exa expert in exa area, i am still to young and scare to go near X server ;)
MrCooper: agd5f: use an LRU list e.g.
glisse: got to run and catch some chocolate
glisse: bbl
MrCooper: agd5f: or just a rolling counter and only updating the current pixmap instead of doing an addition and possibly division for all of them
agd5f: MrCooper: ah ok
agd5f: DMV, bbl
edgecase: so no radeon support for XvMC?
ajax: not yet, no.
edgecase: awww
arekm: hmm, when using tv out on radeon (x300) then lvds blinks once few seconds
arekm: I mean x600 mobile :)
arekm: enable montype: 5
arekm: enable montype: 2
arekm: enable montype: 5
arekm: enable montype: 2
arekm: enable montype: 5
arekm: enable montype: 2
arekm: enable montype: 5
arekm: and this happens... hm I saw some bugreports about this
agd5f: arekm: are you using xine?
arekm: agd5f: mplayer
arekm: #14810 but that's useless bugreport it seems
agd5f: arekm: sounds like something is forcing dpms on events
agd5f: mplay may do somethign similar
arekm: oh, xset dpms force on causes the same effect. Interesting this is that evey call to "xset dpms force on" causes blink but if I stop executing xset dpms force on again and again then ... it also stops blinking
arekm: in other works single "xset dpms force on" causes bliking to stop happening periodically
arekm: s/works/words/
arekm: Another effect observed is that switching panels in kde causes that part of the time audio/video is stopped
arekm: part of the time == 1-2/10 of second
arekm: generally tvout now works. I tried it fews weeks ago (but on another tv) and picture was very unstable
arekm: I'll be able to restest on the same tv in a week
agd5f: arekm: that command forces the outputs on
HotaruT: hi, is there a way to disable software fallback? (File r300_render.c function r300Fallback line 469 Software fallback:ctx->Multisample.Enabled)
bgoglin: HotaruT: maybe disable low impact fallback in driconf ?
HotaruT: driconf? .. ah.. I did not know this tool yet..
HotaruT: bgoglin: it helps, thanks (-:
arekm: agd5f: why the problem is visible only with tvout and not with external vga-0?
agd5f: arekm: what problem?
arekm: agd5f: dpms force on + blinking
agd5f: arekm: output power up sequences are different
arekm: is this considered a driver bug anyway? dpms force on shouldnt do any harm IMO
airlied: MrCooper: EXAMarkOffscreenUsed is bonged.
airlied: MrCooper: it scales really badly depending on the number of offscreen pixmaps.
airlied: so x11perf goes a lot faster if you aren't running firefox.
airlied: for whoever asked, my baseline was a T60P Lenovo
airlied: MrCooper: I'm not really sure what that function is meant to do but clearly its doing it wrong
agd5f: arekm: well, it forces the outputs on. the power on sequence may cause blinking depending on the output. it's not doing any harm
agd5f: arekm: xset doesn't seem to be doing the right thing WRT randr 1.2, is what it boils down to I think
ghepeu: airlied: I was asking about your testing machine. I was trying to figure out if what I see here (x11perf -aa10text with exa ~ 0.25*xaa) was a problem on my part
airlied: ghepeu: stop running firefox when testing :)
ghepeu: I'm testing without firefox :(
ghepeu: X just started, only the gnome desktop
airlied: ghepeu: so what desktop are you running?
airlied: ghepeu: hmm thats what I had as well.
airlied: just a gnome-terminal..
ghepeu: yeah, under metacity or compiz no differences
ghepeu: ~22000 char/s
ghepeu: sorry, before I meant 0.25*exa without hw render acceleration
ghepeu: that is a git checkout as of march 13
ghepeu: pure software
airlied: wierd.. there must be something with some offscreen pixmaps loaded..
airlied: that EXA function doesn't scale well at all.
ghepeu: there's something strange with exa. I noticed that the performances degrades over time and "reboot" with a switch to console and back to x
airlied: ghepeu: I wonder what EXA you are using..
ajax: vt switch will evict all pixmaps, which resets the offscreen scores.
ajax: so, not strange, just a bug.
airlied: oh yes, so that MarkUsed funciton scales badly..
airlied: so with a few offscreen pixmaps it gets totally out of hand
ghepeu: airlied, xserver git, mesa git, xf86-video-ati git, libdrm git
ghepeu: drm modules from kernel 2.6.24 because the new microcode doesn't work here
edgecase: hey do radeon chips support any kind of hardware genlock, ie use external v/hsync ?
agd5f: edgecase: they can use clocks other than the ppll if wired up properly
edgecase: well old school cards like r128 had a header with lots of neat signals, light pen, ext sync, chromakey switcher
agd5f: edgecase: hw hasn't changed that much
edgecase: so there might be pins/balls on the chips, just the board mfr doesn't connect?
agd5f: edgecase: r1xx-r4xx has more or less the same display engine as r128
agd5f: yup
edgecase: r500 is different, maybe it's lacking those features?
agd5f: edgecase: it has them too
edgecase: i don't suppose there's any public docs on pinouts for those features?
agd5f: edgecase: nope, but I don't see why we couldn't release that info if there was interest
airlied: a lot of it would be board manufacturer specific.
edgecase: use case being, you have an HTPC, and someone wants to hookup game PC, normally you'd loose the UI provided by HTPC
airlied: so you'd have to get AMD to let the board makers release it and then actually get the board makers to do it.
agd5f: yup. All we have is the datasheets. the baord makers determine what pins get wired up
edgecase: making the HTPC take external VGA/DVI and become just an OSD overlay
airlied: as having the pinouts on a BGA chips are off no practical value
edgecase: well they are for prototyping, if the balls on an existing board are accessible
airlied: edgecase: prototypes boards are quite different
airlied: edgecase: and more expensive.
airlied: I've got development M7 and M9 cards that cost $3000 each
edgecase: what i mean is, get off the shelf board + datasheet, wire it up myself as a prototype
airlied: edgecase: as I said AMD don't have the datasheety
airlied: edgecase: with that info on it.
airlied: edgecase: as you need the PCB routing
edgecase: i'll make friends with my dentist's X-ray tech
edgecase: i'd still be missing the chip ballout from the datasheet
airlied: edgecase: even then it can be a pain.. as multi-layer boards.
edgecase: sure, there's no guarantee of success, but without chip datasheet, there is guarantee of failure :)
edgecase: if there's some legal work required to release datasheets tho, i'm guessing there would need to be more justification than that
airlied: edgecase: yeah my best guess is it would be mostly pointless..
airlied: edgecase: I've helped design an AGP graphics cards :), so I know how much effort it would take..
airlied: you really would need AMD and board manufacturers help..
edgecase: well there's just a few pins required, the rest could be the same as an existing board
agd5f: edgecase: exactly. I think the datasheets are mostly fine for release, but it would still take time to review and approve them.
agd5f: if you really wanted to do physical design stuff, just sign an NDA and get the sheets
airlied: granted I haven't looked for test headers on most boards..
airlied: I know the development boards have them all...
edgecase: what about the driver side, has anyone seen any code for those features in OS drivers?
airlied: edgecase: not likely considering the hw doesn't exist.
airlied: edgecase: but I would say writing the driver would be a lot easier than x-raying the hw
agd5f: edgecase: probably mostly special case stuff, like setup boxes and tvs, etc.
agd5f: *set-top
edgecase: ok just checked some old cards, 3D Rage/mach64 has a combo VFC/AMC header
edgecase: a Radeon 7000 has the same sized header, but unpopulated
edgecase: so docs have been given under NDA to individual developers before?
PSYCHO___: did somebody solved that stuf with rs4xx when playing textured video and change destop from one to other which lleaves video as black box (resize or fs toggle fix this)
kdekorte: Has any work been done on opening and closing the lid on a t60p (firegl) and X either being corrupt or locking
kdekorte: I'm using the drivers in Fedora 8 and see this problem all the time
airlied: kdekorte: not yet but I see it as well.
agd5f: kdekorte: I'm trying to track that down with the bios guys
kdekorte: ok, at least it is a known problem... probably the biggest one I have... the locking up of X is the most annoying.. the curruption can be fixed with C-A-F1 + C-A-F7
agd5f: kdekorte: the problem is the bios messes with the hardware during lid events and it shouldn't
agd5f: we need to figure out how to stop it on atom-based cards. I've already fixed it for non-atom cards
agd5f: kdekorte: switching the VT fixes it since the hw get re-programmed by the driver
agd5f: PSYCHO___: what app?
PSYCHO___: mplayer
PSYCHO___: with some patches from berkano, xvmc and dvd, bluray stuff
PSYCHO___: but even normal mplayer is doing this
agd5f: PSYCHO___: how about totem or some other app?
PSYCHO___: vlc tested and passed but this stuff screws up when you have 2 displays
PSYCHO___: vlc don't detect but want to config them
PSYCHO___: :(
agd5f: PSYCHO___: ?
agd5f: you mean xinerama hints?
PSYCHO___: xrandr i have
PSYCHO___: vlc is using wierd config, no problem with driver on it
PSYCHO___: this occurs with mplayer only
agd5f: PSYCHO___: sounds like mplayer isn't dealing with the hide/expose properly
loswillios: hm i didn't experience the bug on my rs4xx
MrCooper: airlied: it's been known for a long time... looks like people are finally getting motivated to fix it :)
PSYCHO___: loswillios: what video output, when i use xv it does this when i use gl it hangs for time which i am not on destop with video
loswillios: xv
loswillios: i'll test again tomorrow
airlied: MrCooper: any chnce of a comment on what it does so I can think about fixing it :)
edgecase: seems GPU chip makers have been busy updating the VFC http://www.patentstorm.us/patents/7047330-description.html
MrCooper: airlied: it calculates the cost of evicting offscreen pixmaps
MrCooper: airlied: I described an idea for a fix to fredrikh on #xorg-devel today:
airlied: MrCooper: oops missed that
MrCooper:
MrCooper: fredrikh: in ExaMarkOffscreenUsed, just update the age of the one pixmap
MrCooper: fredrikh: then you can calculate the cost of kicking out a pixmap using the difference between its age and the rolling counter (and possibly other factors such as the pixmap size)
MrCooper:
MrCooper: which should be much less often
MrCooper: I've also had some ideas for defragmenting the offscreen area in a BlockHandler...
MrCooper: is off for tonight, bbl
Magnade: defragmented offscreen area would allow for what just quicker dma transfers?
ghepeu: agd5f, one (or both) of your latest two commits (R3xx/R5xx: use non VAP/TCP for textured video and R3xx/R5xx: move more VAP, etc. state setup into common init3d() function) broke textured video here
ghepeu: at least, I think it was one of those two
ghepeu: start playing video on the textured video adapter, then launch glxgears
ghepeu: the video "wobbles", then I had a hard lock of X
agd5f: ghepeu: what chip?
ghepeu: rv370
agd5f: ghepeu: does EXA still work ok?
ghepeu: as far as i can tell
ghepeu: I didn't test it thouroughly
ghepeu: I was trying to see if the new microcode still made compiz hang, so I upgrade everything and caught the problem
ghepeu: i reverted to the old microcode and it was still there
agd5f: ghepeu: sounds like it may be related to switching between pvs-bypass and non bypass mode
agd5f: since the 3D driver uses the TCL/PVS hw and the ddx doesn't now
ghepeu: if you want i can revert only those two commits and see what happens
agd5f: the 3D driver probably needs to flush the pvs pipe or to make sure pvs is re-enabled
airlied: hmm should happen in the drm.
agd5f: airlied: how often does the 3d driver emit R300_VAP_CNTL_STATUS?
airlied: agd5f: it should do it when it loses context..
airlied: agd5f: unless there is a state atom emission problem
airlied: ordering etc.
agd5f: we shold probably add a pvs flush there to clear the pvs pipe before changing that register
agd5f: or after I guess
RoiDuClapier: I'm currently studying the drivers source and I must say that is looks pretty clean
Magnade: is render working for r300 yet? a couple of the commits of recent make it sound like it is
agd5f: Magnade: yes
Magnade: agd5f: does render require exa then? as im using xaa and it says its disabled and unsupported
airlied: Magnade: yes.. EXQ
airlied: EXA even
Magnade: the unsupported comment then is rather confusing
agd5f: Magnade: only exa render hooks ahve been implemented
agd5f: do to limitations of xaa, it makes it hard to accelerate render operations in xaa
Magnade: i see
Magnade: guess ill try out exa then
onestone: agd5f: airlied: Any change to get some pseudo code (like ARB_fragment_program) comments to the current textured video and exa shader code, to make it easier to understand?
airlied: onestone: its two instructions long :)
airlied: and is basically put texture into output :)
airlied: for textured video
agd5f: onestone: I added some comments to the render code and the two paths are nearly identical
onestone: airlied: but event two calls are more code examples than 0 ;-) A tool that would allow to play with some shader code would be even better. i would really like to transform my bicubic filter compiz ARB_fp code into a r500 textured textured video code
agd5f: onestone: take a look at R300PrepareComposite() in radeon_exa_render.c
onestone: agd5f: will do thx
airlied: onestone: glisse was thinking about making r300_demo do that
agd5f: onestone: we don't actually use the shaders for anything at the moment in the textured video code
airlied: but yes the first instruction is sample texture 0 to register 0, the second output register 0
agd5f: they just pass the textures through
Magnade: well exa looks to work and render says its good the fun part is it looks like gimp is slower in exa :\
onestone: airlied: so something like texture 0 to register 0, do some math with register 0 into register 1 and then output register 1 would work?
agd5f: onestone: you can use up to 32 temps
airlied: onestone: pretty much, thats how you would add brightness and stuff I think.
agd5f: we just use 1 since that's all we need to pass the texture through
airlied: onestone: but as the hw can deal with YUV textures we don't have to do much with them
onestone: I will look deeper into the code tomorrow and ask questions here if I find something I don't understand. But a demo tool would be really nice, beause always compiling the driver and restarting X isn't fun
edgecase: are the recent docs released, including what's needed for XvMC?
Magnade: hmm no i guess xaa is about the same speed in gimp
airlied: edgecase: nope.
agd5f: edgecase: we haven't released the idct/mc stuff yet
onestone: airlied: agd5f: this is what i would like to have for video too http://img442.imageshack.us/my.php?image=bicubiccg0.png
airlied: onestone: nouveau uses a bicubic shader to do one xv adaptor.
airlied: onestone: so it shuoldn't be that hard to figure out.
onestone: I know
airlied: onestone: depending on the size of the fragment program required of course
airlied: it might be nice to write a better instruction encoder to avoid the hand written shaders.
onestone: airlied: As said, this is my compiz bicubic plugin and it works fine here on my x1400 with fglrx
dli: how do I test the mesa r500test branch? I checked it out, added my chipset id 0x71d4, built mesa, restarted X, still no 3d
airlied: dli: what does glxinfo say.. are you loading the write libGL, etc..
dli: direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
airlied: dli: so what does LIBGL_DEBUG=verbose glxinfo say? :)
dli: libGL error: dlopen /usr/lib64/dri/r300_dri.so failed (/usr/lib64/dri/r300_dri.so: cannot open shared object file: No such file or directory)
airlied: dli: so use LIBGL_DRIVERS_PATH and possibly LD_LIBRARY_PATH
dli: airlied, I don't have /usr/lib64/dri/r300_dri.so
airlied: dli: mesa isn't the smarttest about paths etc.
airlied: dli: it also depends on your distro.
airlied: dli: usually easier to set the two variable above to the mesa/lib subdir
dli: airlied, no, I have to build it
mcquaid: hello i have a radeon 9000. everything seems ok but a couple of issues. what i'm trying to deal with is xv output has the colours wrong
mcquaid: people look green in videos, red looks swapped with blue
mcquaid: i tried opengl output with mplayer and colours were fine. but i'm using an app that only has xv
agd5f: mcquaid: textured video or overlay?
mcquaid: i believe overlay but i'm not sure to be honest. first time setting an ati card
mcquaid: using latest xorg which uses a minimal xorg.conf so those things aren't set
mcquaid: textured video... is that using opengl ?
agd5f: mcquaid: textured video uses the 3D engine to render video using textures. it shows up as an Xv adapter though. it was only recently added though
mcquaid: ah. well i manually choose opengl in mplayer and that was fine. is there a big cpu hit using textured video over overlay?
mcquaid: i don't see textured video mentioned in the man page
mcquaid: what about opengloverlay?
mcquaid: finding options that aren't mentioned in the man, not sure what applies. it seems using textured video you have to manually select it as it's not default
mcquaid: is that still true if you use VideoOverlay off
Magnade: sounds like your using fglrx rather than radeon driver
agd5f: mcquaid: your driver is probably too old, as I said ti was just added recently. it's not in the man page since it just shows up as another xv adapter, no special configuration required
agd5f: mcquaid: sounds like you are using fglrx
agd5f: though
mcquaid: no definitely using xorg's driver, i don't have fglrx installed
mcquaid: i just tried textured video on and it made video colours fine in mplayer playback
mcquaid: but mythtv seems to still use the wrong colours. i tried video overlay off cause i believe with textured video there is now two xv outputs and i think myth is defaulting to the wrong one
mcquaid: latest myth has an opengl outout option which fixes colour, but cpu goes really high
mcquaid: strange that opengl in mplayer using textured video is fine cpu wise
moondrake: textured video also seems broken for me:( Seems similar to something osiris reported some weeks ago
moondrake: two colored triangles
agd5f: moondrake: update to the latest git code
agd5f: also, make sure you have a recent drm and and have the dri enabled
mcquaid: i'm using the version from hardy beta
agd5f: mcquaid: mythtv probably defaults to the first XV adapter which is the overlay
agd5f: textured video uses the 3D engine, but it's not the same as the gl output options in mplayer, et. al.
moondrake: agd5f: I updated (drm+ddx) yesterday. I have to check for dri though
agd5f: moondrake: what chip?
moondrake: R500, X1400
moondrake: agd5f: the fun thing is, it worked yesterday after switching from fglrx to ati
moondrake: dri is loaded. perhaps i should update mesa...
agd5f: moondrake: it may have been my or airlied's last couple commits
agd5f: moondrake: mesa is not involved in textured video
moondrake: ah..I found something on phoronix who had the same, then updated all including mesa and it worked. I thought i might try it
agd5f: coincidence I would say
moondrake: agd5f: osiris said running a 3D app first fixed it for him. But currently I cannot on r500 or can I?
agd5f: moondrake: 3D is only preliminarily supported at the moment. I suspect it's related to the VAP changes from the last 20 hours or so
moondrake: k I bisect later. First lunch then
mcquaid: agd5f, is there a way then to make textured video the first xv, so it should work with any player?
mcquaid: i would think it would be the first if video overlay is disabled but that didn't work
agd5f: mcquaid: you can change the order that the adapters are added in the code
agd5f: mcquaid: there's no way to disable the overlay
mcquaid: ah
agd5f: or textured video for that matter
agd5f: other then editing the code
agd5f: both are enabled by default
mcquaid: hmm, i'll have to doublecheck but i think mplayer only showed right colours with xv ouput once i put "TexturedVideo" "on"
mcquaid: i guess i'll see if the xv device can be specified in myth but i don't think so
agd5f: mcquaid: there's no such option
mcquaid: i must have still had opengl enabled in mplayer's config
mcquaid: but myth also works with fbdev colourwise anyway
mcquaid: but that has no hardware assist for video playback correct?
agd5f: mcquaid: I don't follow. what do you mean "works with fbdev colourwise" ?
mcquaid: well my initial problem is, xv has wrong colours. people look green. red looks blue.
mcquaid: fbdev displays normal colours as does opengl
mcquaid: and i'd assume texture video if i could indicate the xv in myth
agd5f: when you say fbdev, what do you mean?
agd5f: are you running radeon or fbdev?
mcquaid: i am running radeon
agd5f: ok. I'm not sure what the fbdev you are talking about does. is it an output option or ...
mcquaid: ok not knowing this stuff exactly, put isn't fbdev a frame buffer device, that gives direct access to the hardware
mcquaid: but isn't
agd5f: there's an X driver called fbdev that runs on a kernel framebuffer device, it might also refer to a kernel framebuffer device
agd5f: perhaps mplayer can open kernel frame buffer devices directly (outside of X) and output to them directly
agd5f: for some sort of multi-head sort of thing
mcquaid: yes mplayer has a fbdev option as well
mcquaid: http://www.mplayerhq.hu/DOCS/HTML/en/fbdev.html
agd5f: ah
mcquaid: i might live with fbdev for now then. but is it normally cpu intensive for video playback vs xv?
agd5f: I think fbdev does nothing in this case (probably falls back to X11 or Xv)
mcquaid: yeah i thought it might be x11, hoping it wasn't
agd5f: mcquaid: you can disable the overlay with a quick patch