udovdh-afk: Honk, you had a problem?
Honk: udovdh-afk: geesh
udovdh: Honk, don't remember every pronblem that someone has. Let's have aparty now that even those nasty bugs that would make the hd driver less useful are (for now?) gone...
Honk: udovdh: you should remember if someone has the same problem as you :P
Honk: and talks to you about it =D
Honk: well.. maybe you shouldnt
Honk: *shrug*
udovdh: otoh: there were no release notes yet
udovdh: and maybe they were just alpha-etsting ;-)
udovdh: testing...
Honk: release notes? i'm building from git anyway :P
udovdh: does git provide release notes? ;-) (just some check-in descriptions)
udovdh: I was wondering: is there some overview available of the API between the driver and Xorg so we could see what functions are covered by the driver and which not (yet)?
udovdh: carldani, are you there?
udovdh: I read about the spi stuff from earlier today/yesterday
carldani: yes
udovdh: can you confirm one can reflash the bios with that method?
udovdh: of the hd card I mean
carldani: I have working bios readout on r6xx
udovdh: read, but also write?
udovdh: (read: you spi method is same output as memory mapped readout?)
carldani: for write I'm missing register definitions on r6xx
udovdh: ah, too bad
carldani: I'm pretty sure the registers exist, but i don't know their location
udovdh: for my hd2600pro gigabyte only has a win32 flash application
udovdh: (so far, that is, I asked them about it)
udovdh: so a native linux method would be great
udovdh: the motherboard though, can flash itself. just need media with the bios
carldani: right now I'm porting my readout code to r5xx because with luck, I will be able to flash stuff there
carldani: hd2600pro is r6xx?
udovdh: ah, interesting.
udovdh: indeed rv530 if I am correct
udovdh: 630
udovdh: rv630... grr
carldani: udovdh: and you said there is a win32 flash util for your card?
udovdh: self extracting win32 flash app (w/ bios) is 770 kb
udovdh: yes
udovdh: gigabyte has it online
udovdh: need url?
carldani: yes please
udovdh: mom
udovdh: http://www.gigabyte.eu/Support/VGA/BIOS_Model.aspx?ProductID=2589
udovdh: then choose bios
udovdh: http://www.gigabyte.eu/Support/VGA/BIOS_DownloadFile.aspx?FileType=BIOS&FileID=13087 is closer
carldani: downloading right now
carldani: ah. rar selfextractor
udovdh: indeed. just unrar
udovdh: one batch, textfile, some language dlls
udovdh: and the main exe with bios included
udovdh: but it needs win32 :-(
carldani: so what?
udovdh: don't have that here
udovdh: the sys files may have the clue for you
udovdh: you have a workaround, carldani ?
carldani: narf. the extracted exe is a "ms assembly"
libv: carldani: surely some x86 assembler never stopped anyone
udovdh: assembly?
udovdh: you mean not compiled c(++)?
carldani: no, ms assembly file format. some strange c# file format
carldani: x86 assembler has not stopped me before.
libv: hrm, would ximians mono have some sort of basic decompiler :)
udovdh: interesting.
udovdh: would the .sys names tell anything?
udovdh: ati llk64.sys
udovdh: ati kia64.sys
udovdh: ati dgllk.sys
udovdh: (without the spaces)
udovdh: maybe just run and set a breakpoint when it does i/o to the flash?
udovdh: carldani, c# would explain the size of the exe
udovdh: rom is only 64K I assume?
carldani: 64k or 128k
udovdh: at least that was the extracted size of rhd_conntest -d
udovdh: so a 700K exe, plus extra files...
libv: pci rom bar is 128k on R* and Rv*
libv: udovdh: rhd_conntest -d only dumps the C segment from /dev/mem
udovdh: so what is missing? D?
ndim: For the record: the radeon-without-hd driver also has problems on X1400 when switching between VGA text console and X11.
libv: ndim: are the problems still there now?
udovdh: with the git version?
libv: ndim: yeah, of course, but there the problem will be much worse as they never have any idea of what atombios is doing for them and thus can never restore things :)
libv: udovdh: yes, with the git version of our driver
libv: udovdh: i have fixed 2 things which could fix this
ndim: libv: Well... so far, the problem symptoms are easier on radeon-without-hd. I have to build a new radeonhd, however :)
libv: what do you mean easier?
ndim: Appears only in 30% (instead of 60%) of cases. Still flickers, but less irritating.
libv: ok..
libv: heh, of course, no real attempt to recalibrate the pll is being made
libv: i'm amazed that this works at all
sonne: libv, regarding #13474, see http://nn7.de/debugging/Xorg.0.log
libv: sonne: ah :)
libv: great, direct communication :)
sonne: yeah I thought it could help ;-)
libv: and the last bit in there is what has the problem?
sonne: libv, in the last bit I did another xrandr --auto after disconnecting the tft
sonne: libv, I now reconnecyted the tft and did xrandr --auto and the log now is this http://nn7.de/debugging/Xorg.0.log_new
libv: ok, hrm, but this is a macbook :p
libv: my previous commit should've made anything that got messed up with respect to data ordering at least uniform
libv: so this is not some endianness issue
libv: becker uses a t60, so this is not the issue here
sonne: libv, it is not a macbook it is a macbookPRO :P
sonne: (where pro stands for PRO in triggering bugs)
egbert: sonne: from this side of the ocean they all look the same :p
sonne: actually there is no macbook with ati gfx
sonne: only intel...
sonne: and only the first two generations of the mbp's were ati (mbp1,1 and 2,2)
ndim: is building radeonhd with the vsync 0/null fix.
libv: ndim: if it is spread spectrum related, then this probably won't fix the issue :)
libv: sonne: hrm, my m56 seems to be doing a good job :(
libv: ooh, but i can kill X too
libv: ooh
libv: i have breakage!
libv: kisses all the bits of hardware involved
libv: sonne: i have a buggered up screen now too :)
sonne: libv, great :-)
sonne: good work
libv: yes
libv: and i know, i am a sad, sad man
sonne: luckily it is not friday yet ;-)
libv: i am happy when something breaks, and then i get physical with the breaking hardware ;)
sonne: enjoy it ;)
libv: urgh
libv: and i spot nothing in the registers
udovdh: so a defect or a bug?
libv: oh, it definitely is a bug, no doubt about that :)
libv: aha
libv: gamma issue
libv: running xgamma fixes it
jq: libv: ping
carldani: udovdh: ping
udovdh: icmp reply...
udovdh: what's the issue carldani ?
carldani: udovdh: you pointed me to the ati flash tool for your graphics card. have you ever used it? does it take parameters?
udovdh: see the batchfile that goes with it
udovdh: that's all I know
udovdh: the app gives an error level for ok or not
udovdh: and is started without parameters
carldani: udovdh: because the binary I extracted from the selfextracting binary is one big "archive", I tried to extract single files, but I have no way to extract them.
udovdh: what is the archive type?
carldani: if I knew that, I would have extracted the files.
carldani: unshield, unrar, cabextract, unzip all fail
udovdh: hmmm
carldani: and it seems not to be packed because the bios is in there verbatim
udovdh: hmm so the exe loads that all into ram and uses a pointer to the rom
udovdh: one of the exe format features?
udovdh: file says
udovdh: msdos exe pe for ms windows
udovdh: or similar
carldani: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit
udovdh: indeed. nothign special?
carldani: objdump says "file format efi-app-ia32"
libv: ah, hrm, jq left already
udovdh: maybe some exe tool (a manual version of the loader) can split the exe in the parts that it has?
udovdh: the program, overlays, rom, etc
udovdh: or try exe2bin.exe ?
udovdh: ;-)
udovdh: won't work due to the sizes
udovdh: sorry I cant help you there
shosca: udovdh: i just tried to open the exe in visual studio. I see these: http://link.imgshare.us/bipQK8
udovdh: lemme see..
udovdh: interesting.
udovdh: so what do you want to check out?
udovdh: I see a rom and stuff
udovdh: I'd like to flash that rom without win32
udovdh: what would you like? the flashing code?
Honk: argh
udovdh: ?
Honk: who removed the git-build from the overlay? :P
shosca: i have the rom bin. the rest is icons and stuff
carldani: hm. very interesting.
shosca: anybody know a place where i can put it?
carldani: shosca: can you take a look at http://www.techpowerup.com/downloads/854/Winflash_2.0.0.2.html as well?
shosca: carldani: http://link.imgshare.us/bipRpO
carldani: shosca: you may need to unrar first
carldani: thanks
carldani: bbl
FlyingSpaghetti: i'm trying to implement GPGPU. i'm looking at this page (http://en.wikipedia.org/wiki/Comparison_of_NVIDIA_Graphics_Processing_Units#GeForce_8_series). can someone please explain what which clock rate matters most? (core, shader, memory). it is hard for me to determine which is used most during GPGPU or if it is dependant on the way i program
FlyingSpaghetti: (i know it's not directly related to radeonHD, but i don't really know where else to ask)
udovdh: hmm...
udovdh: does ati also have dos flashers? would they work on a gigabyte card with ati chip?
udovdh: they have a dos flasher. hmmm
rmh3093: is there any news on the tv out or 3d front?
libv: rmh3093: nope
rmh3093: libv, what is is new... i havent talked to anyone in here in a week or so
libv: rmh3093: bugs fixed mainly
libv: rmh3093: quite a few of them
libv: we still have a few to go too
rmh3093: i love how much cooler my computer is with the radeonhd driver
rmh3093: ;)
libv: well, i think that is just because we neatly disable things, i hope
libv: not that we ever really reviewed any code for this specific goal though
rmh3093: well only doing 2D i cant imagine the card making much heat
rmh3093: however
rmh3093: fglrx computer gets really hot
rmh3093: ever since the driver release before aiglx support came out
rmh3093: and set-powerstate=1 only helps a little
libv: rmh3093: we are not even doing 2d
libv: rmh3093: we are doing modesetting
rmh3093: im not sure I understand how what the radeonhd can accomplish is not 2d
libv: rmh3093: 2d means 2d acceleration
libv: rmh3093: we are doing none of that
libv: rmh3093: all we do is make sure that framebuffer content shows correctly on whatever display combination you want
libv: or... modesetting
rmh3093: i see
rmh3093: so basically radeonhd is to fglrx as nv is to nvidia..... at this time
mjg59: No, nv provides 2D acceleration
dli: but nv is so buggy (though not sure whether it is still so)
Fry-kun: hello
Fry-kun: I've just set up radeonhd on dell e1505/6400.. the panel has the right resolution (1680x1050), but the secondary monitor only gives me 1280x1024 (instead of its native 1680x1050)
Fry-kun: i've had this problem with fglrx as well, for a while (don't remember how I finally fixed it there)
libv: Fry-kun: edid problem?
libv: Fry-kun: what is the preferred resolution of this monitor?
Fry-kun: i suspect, yes
Fry-kun: 1680x1050 is native on both panel and external
libv: preferred resolution is a term specific to EDID
libv: not a general statement
Fry-kun: oh, sorry
libv: EDID has a bit which says "first detailed mode is preferred mode"
Fry-kun: http://pastebin.org/12190 <- Xorg.0.log
Fry-kun: oh yes, i remember now.. the way i fixed it with fglrx was hardcoding the refresh setting in xorg.conf - after that it worked fine (even when i removed the setting)
libv: hrm
libv: Manufacturer: TPE Model: 7d6
libv: with a preferred resolution of 720x480
Fry-kun: that's a damned lie if I ever heard one
libv: it's what is said here
Fry-kun: might the vga connection be to blam
Fry-kun: +e
Fry-kun: nono, i don't mean you - i mean EDID :)
libv: Ranges: V min: 55 V max: 76 Hz, H min: 30 H max: 82 kHz, PixClock max 140 MHz
libv: no
libv: what is to blame is that there is no way for the driver to read in this edid block that this is a monitor which is reduced capable
libv: use Option "ForceReduced" "True"
libv: in your device section
Fry-kun: cool, i'll try it right now
Fry-kun: brb
libv: and then... a 1680x1050 mode at reduced blanking timing should be perfectly acceptable
Fry-kun: nope, didn't help :(
libv: 21:10 < libv> and then... a 1680x1050 mode at reduced blanking timing should be perfectly acceptable
libv: provide a modeline generated with cvt -r
Fry-kun: ah
Fry-kun: that's in the monitor section?
libv: no, in a modes section, to be included in a monitor section
Fry-kun: k, trying
Fry-kun: hrm.. well, the external monitor now says it's receiving 1680x1050 64KHz 59.9Hz - but it can't adjust, somehow
Fry-kun: i guess the refresh info is not to its liking
libv: ?
Fry-kun: it looks like a reduced resolution, but info popup says it's 1680x1050
Fry-kun: and autoadjust doesn't help (usually it does, when resolution is right)
Fry-kun: ah, i think it likes 64.8 hsync
Fry-kun: oh.. that's pretty much right... o_o
libv: what brand/model is this monitor anyway?
Fry-kun: some generic brand
Fry-kun: says "Starlogic" on the front
Fry-kun: why doesn't EDID data have the right settings?
Fry-kun: or is it that the driver can't read it?
Fry-kun: oh, a different problem: since installing radeonhd, i've been getting messages from the kernel:
Fry-kun: Uhhuh. NMI received for unknown reason b0 on CPU 0.
Fry-kun: You have some hardware problem, likely on the PCI bus.
Fry-kun: Dazed and confused, but trying to continue
libv: Fry-kun: yes, we have a bug open on that
Fry-kun: pretty sure the only thing I changed to cause this was uninstalling fglrx and installing radeonhd
Fry-kun: oh, good, so i'm not the only one :)
Fry-kun: i can ignore the error for now, yes?
libv: https://bugs.freedesktop.org/show_bug.cgi?id=13480
Fry-kun: (looks like the https certificate is not valid)
libv: yes, fd.o issues
Fry-kun: sooo.. what do you think about setting the right resolution?
Fry-kun: will it ever work?
libv: it works, doesn't it?
libv: it should at 1680x1050R
Fry-kun: no, the image is pixelated
libv: are you certain that it really is running at that resolution?
Fry-kun: and the sides are off-screen
libv: heh, that's rather awkward
libv: this is a panel, right?
Fry-kun: like i said, it looks to the eye like it's running on lower resolution
Fry-kun: but when i press the menu button it says it's 1680x1050
Fry-kun: yeah, it's a flat panel
libv: heh, a rather broken one too
libv: it should be perfectly able to accept this mode
Fry-kun: (i didn't know crts were even made with wide screen modes)
Fry-kun: yeah, i would think so :(
libv: well, edid blocks can be wrong
libv: provide frequency information in a monitor section
libv: and bump the bandwidth to 147
Fry-kun: going to play around a little, bbl
Fry-kun: libv: still no success. although i did notice that the monitor reports 65kHz/59.8Hz in proper mode (in WinXP)
Fry-kun: (currently says 64kHz/59.9Hz, and doesn't display full resolution)
Fry-kun: i also downloaded a windows utility that shows the detailed settings currently used - slightly different from what cvt gave me - trying them didn't help
Fry-kun: also there's a mention on fedoraforums (offhand comment) that starlogic "has a faulty EDID that only drm'ed windows recognizes"
Fry-kun: fglrx was able to work with it, after a small setting change.. they probably put some workaround into it..
ajax: Fry-kun: do you have a link to that forum post?
ajax: nm, google knows all
Fry-kun: http://fedoraforum.org/forum/showpost.php?p=868713&postcount=20
Fry-kun: heh
ajax: shame he didn't also post his EDID.
Fry-kun: can always PM him and ask to do that
ajax: wow, fedoraforum is possibly the worst UI ever
Fry-kun: oh, one more thing: that windows utility that i used to check the info, said that EDID could not be read
libv: Fry-kun: which is weird, as X would've returned nothing if the checksum was bad
Fry-kun: ugh :(
ajax: i'm considering doing a hex dump even on failure
ajax: oh, there we go, i was looking at the "pda" version. real version is slightly less of a disaster
airlied: ajax: kernel code does some "patching" attempts to fixup EDIDs..
airlied: ajax: like it goes hey that header isn't correct, puts in correct header and rechecks checksum..
airlied: this is the fbdev edid..
ajax: yeah, i saw that fixup.
libv: just the FFs?
airlied: libv: yup..
libv: hrm, anything else it would try to do for itself?
libv: because afaik, there is not much room for that
airlied: the other two fixups are fairly standard quirks, one for analog vs digital misreporting, and one timingsd..
libv: but yeah, dumping when the checksum is bad seems good
airlied: but the header fixup actually proved useful on one of the crappy montiors I toasted..
airlied: as I only toasted the first two bytes of EDID
libv: airlied: analog versus digital? how would it go and do this?
libv: airlied: it would have to have quite some knowledge about which output this edid block is associated with
airlied: libv: just patches the reported bits.. I think there is a monitor that says digital over VGA..
airlied: yes its monitor specific in that case
fireburn: Hi just logging on to say a big thank you for the HDMI patch the other day
fireburn: '#]'#'
carldani: hi
libv: fireburn: --> egbert_away :)
Fry-kun: airlied, libv: so, where does this leave me and my immediate problem? will there be a fix in the near future, or do i need to go back to fglrx for now?
libv: Fry-kun: so the bandwidth stuff didn't help?
Fry-kun: "bandwidth stuff"?
libv: Fry-kun: if you force a slightly higher bandwidth, you could try to run a non-reduced 1680x1050 on this monitor
Fry-kun: how do i do that?
Fry-kun: oh, is that the 1st part from cvt setting?
libv: from man xorg.conf: in the monitor section: Option "MaxClock" "frequency"
Fry-kun: trying
Fry-kun: libv: didn't work (although i may have written the settings wrong). I don't have any more time to play with it right now, will drop by this channel tomorrow around the same time
Fry-kun: thanks for your help!
carldani: udovdh-afk: ping
carldani: udovdh-afk: in case you read that later, it may be possible to specify a few parameters to the flashing program... I'm trying to figure them out
tgilber1: I am having trouble getting the radeonhd driver working with my 2400HD apdapter - using Ubuntu Gutsy/7.10
tgilber1: the gdm/:0.log files has comments like get-edid cannot retrieve edid data
tgilber1: the proprietary version from ati/amd works
tgilber1: but I cannot get the ubuntu to work
tgilber1: additionally, when I create a compiled version from the proprietary at run file, it does not work. Only the standard setup file works
tgilber1: sorry for the typing errors
tgilber1: bottom line, the proprietary version install the fglrx kernel object, which works ok
tgilber1: however, it does not work when using the X driver, radeonhd_drv.so
tgilber1: this driver gives me the get-edid error
tgilber1: btw, i am using x86_64 platform - ubuntu
rbmorse: Hi there. I've got the radeonhd driver running on 7.10. I installed
rbmorse: from git using the instructions from the radeonhd wiki, except
rbmorse: instead of running install at the appropriate time, I had to
rbmorse: change the command to sudo make install. When that finished
rbmorse: I ran sudo make clean then restarted the session with
tgilber1: I used the git wiki howto, also
tgilber1: but to no avail
tgilber1: is there a read-edid package for ubuntu x86_64
tgilber1: ?
rbmorse: did you make install as root...using sudo?
tgilber1: yes
rbmorse: Are there any obvious errors in /var/log/Xorg.0?
tgilber1: without the proper persmission, make install could not install the drivers in the /usr/lib/xorg/modules/drivers/ directory
tgilber1: yes
tgilber1: Could not retrieve EDID because get-edid is not installed
rbmorse: Odd...sudo should have taken care of that. You need to be root at that point.
tgilber1: there are no failures installing
tgilber1: the driver
tgilber1: sudo works
tgilber1: fine
tgilber1: sudo make install
tgilber1: its when I try to load the driver that it fails
rbmorse: Which driver _is_ loaded?
tgilber1: it defaults to the failsafe xorg.conf, which loads the vesa driver
rbmorse: and if you manually edit xorg.conf to change "vesa" to radeonhd" in the device section, it still goes back to failsafe?
libv: tgilber1: check in something like /usr/lib64/xorg/modules/drivers/
libv: tgilber1: are all the other drivers there? is radeonhd there?
tgilber1: yes
rbmorse: That reminds...when you did the autogen script, did you specify --prefix=/usr/..., i.e., ./autogen.sh --prefix=/usr/
tgilber1: Both the 32 and 64-bit libraries have the driver
libv: tgilber1: what happens if you specify radeonhd in your config file?
tgilber1: radeonhd that is
tgilber1: I did a full reboot, and gdm tries to start
tgilber1: but eventually fails over to the failsafe xorg.conf
tgilber1: thereby loading the vesa driver
libv: tgilber1: so what does the log state when trying to run our driver?
libv: why does it fail?
libv: tgilber1: there should be an Xorg.0.log.old
tgilber1: the error message in the Xorg file state that it cannot retrieve the edid data
tgilber1: need to install get-edid
tgilber1: however, if I replace radeonhd with vesa, it has no problem loading from the get-go
tgilber1: it reads the edid fine
libv: tgilber1: get-edid is a big batch of nonsense
libv: tgilber1: get-edid works with vbe or with whatever support it has internally
tgilber1: I tried to install the read-edid source but it would not compile on the x86_64 platform
libv: tgilber1: and will not be able to talk to all three of the ddc busses our hardware typically has
libv: tgilber1: and will also not be able to decide which edid info is tied to what
tgilber1: there is no issues when using the proprietary version, which installs a kernel object module
tgilber1: rather than use the X driver radeonhd_drv.so
libv: tgilber1: i really don't understand why anything would want to ask for get-edid
tgilber1: act of desperation, since it was appearing the log files
tgilber1: hence, I thought it might be worth a shot
tgilber1: in any event, it did not work
libv: send the log of your radeonhd run to our mailinglist
libv: the details are on the wiki page in the /topic
tgilber1: thanks, will do
rbmorse: libv -- while you are here, I notice that in the installation instructions on the wiki, at the point one needs to run make install the wiks shows that being run at user level rather than root. The only way I could ge the install to work on Ubuntu 7.20 and 8.04 was to run make install with sudo. Is this Ubuntu (or Debian) specific?
libv: rbmorse: can you mail this to the ml as well?
libv: rbmorse: so that we don't forget it, it's 2.00 here now
libv: rbmorse: super user access is of course required if you want to install something like this
rbmorse: Sure. Be happy to. Thanks...get some sleep.
libv: rbmorse: it is also required when you install any other driver
rbmorse: Yeah...I'm sort of new at all this and still learning the basics.
Fry-kun: i see there's a known issue about hardware cursor corruption. is there a bug assigned to that?
Fry-kun: i get it too, looks like - the [fairly small] area around the cursor shows flickering lines (seems random), and the problem disappears if I move the cursor or wait a little while
Fry-kun: just had the cursor corruption happen again
Fry-kun: wasn't doing anything special, just editing a file (scrolling, perhaps). corruption showed up only on the right side of the cursor, within 10 pixels only. black horizontal lines appeared and disappeared randomly. problem disappeared as soon as i moved the mouse
libv: Fry-kun: ah, line buffering again i guess?
libv: Fry-kun: we have a really cute bug locally on an rs690 laptop
Fry-kun: "again"?
Fry-kun: cute? :)
libv: we see the first four lines of the cursor repeated throughout the full height of the cursor
libv: triggered by moving the cursor in virtual, in the lower right corner, at slightly higher speeds
Fry-kun: ah
libv: and it get fixed again when moving the viewport to the right only
libv: the actual trigger is the crtc side frameadjust
libv: not any of the cursor handling
libv: the image in the fb is also correct
Fry-kun: so.. no need to file a bug?
libv: there's a bug about this already
libv: well, many of them, all are now pointing to the same though
Fry-kun: :)
libv: our local bug has not been filed
libv: but i suffer from it all the time so it will also get handled as soon as we get more grip on what is really happening
Fry-kun: ah okay
Fry-kun: the cause is probably the same.. but even if not, it doesn't happen too often to me
libv: or at least related
Fry-kun: i shot a 5-sec video with my cell phone to demonstrate the problem, if you're curious ;)
libv: Fry-kun: no thanks, not worth the hassle of uploading and stuff
libv: Fry-kun: we have a lot of people suffering from linebuffering issues at the moment
Fry-kun: gotcha
Fry-kun: oh, by the way: when i was using fglrx, i got cursor corruption too - though that one looked different
libv: :)
Fry-kun: but the thing is, it made it obvious that the size of the hw cursor is a pretty large square (32x32 or higher)
Fry-kun: obvious because corruption was around the cursor in that radius, and moved around with the cursor
Fry-kun: but with this bug, there's barely anything, and it's within a few pixels of the cursor only
Fry-kun: so i'm curious, is the cursor size different?
Fry-kun: or is it just because the bug is different
Fry-kun: whoa
Fry-kun: well, this is unexpected:
Fry-kun: i just noticed that this corruption happens every time the cursor reaches a certain vertical line
Fry-kun: and it's reproducible, right now
Fry-kun: on EVERY 240-th (approximately) vertical line
Fry-kun: wonder if restarting X will make it go away...
Fry-kun: doesn't happen on external monitor, only on lvds
Fry-kun: is this at all helpful?
Fry-kun: just restarted X, the cursor corruption is still there. it disappears when I restart X with external monitor disconnected - and comes back when it's i restart with it connected