I just bought a AOC E1649FWU displaylink secondary monitor to play with it. It mostly works but has issue with the only available mode it works with: 1366x768 After a long chat on IRC with ajax I was able to create a 1360x768 mode that makes the display usable for now.
Log of the IRC chat: <simo> are USB DisplayLink devices suposed to work with F20 ? <simo> I just got one for cheap and xrandr sees it <simo> but if I turn it on I see only garbage displayed<simo> oh interesting <simo> if I move the mouse in it does a "canceling effect" where the rubbish is deleted and replaced with the actual background image where the mouse goes <simo> os it does kinda work, but it is a little bit awful <ajax> weird. <simo> if you move windows around sometimes it "forgets" to delete part of the image and replace it with the background <simo> maybe I should try using a uniform color background ? <simo> I guess it could be a bandwidth issue and dropped "frames" ? <ajax> the driver doesn't work like that, it's not really frame-based. <simo> also interestingly there is like a 5/10 pixel band on the right edge that never gets cleared <simo> ajax: from what I can see rectangles around what is changing on the screen are being transferred ? <ajax> right. there's a "shadow" framebuffer in host memory, when its contents change we shove those pixels over the usb cable, the device has a framebuffer internally that it scans out of <simo> ajax: so something is failing to transfer data when a window moves aout and only the background is left <ajax> that it initially displayed garbage presumably means we failed to do an initial "everything's damaged" update <simo> the actual window internally seem to be completely redrawn <simo> ajax: it keeps doing that though <simo> seem like somehow the root window is never transfered over when something on top moves out ? <simo> (not sure if that's what's going on, but it is how I see/can explain it) <ajax> that's... possible, but weird. <simo> uhmm also when pressing the super key to bring up gnome-shells activities window the usb display does not get redrawn at all <simo> yeah it definitely looks like some times updates are dropped * simo tries to find a faster usb port <simo> ajax: uhmm no attaching it to another port (in the back of the case, different channel) didn't make a difference <ajax> simo: any update you're seeing being missed isn't a function of bandwidth <ajax> that's not a thing the driver knows about <ajax> mclasen: i saw! i even went to pop the patch into the fedora package and saw i'd been beaten to it <simo> ajax: ok so anything I can tweak/test ? <ajax> simo: try a non-composited session? would isolate the issue to the direct rendering code at least <simo> ajax: how would I do that ? <ajax> good question! <simo> I can attach it to a test machine so I can start any other dm/wm <simo> but it would be the only display there :) <ajax> i usually switch to a vt and do X -ac -noreset -retro :1 &, vt switch back, DISPLAY=:1 metacity &, DISPLAY=:1 gnome-terminal &, vt switch back to X and go from there <ajax> i'm sure there's other "full desktops" that give you the twm experience but i never use 'em <simo> ajax: so you start a second X server on that display ? <ajax> yep <simo> let me try <simo> ajax: do you have to vt switch ? <ajax> i suppose you could run all that from a terminal in the original session... <simo> uhmm <ajax> but yes, the second X server _will_ be on a different vt from the first one <simo> the first command did start X ... but on my main card <simo> not on the other disaply <ajax> that's what i wanted, yes. <simo> how do I tell X which display to start on ? <ajax> you're going to then attach the udl device to the other X server <ajax> you don't! <simo> ah <simo> ok let me go on <ajax> (though the dbus-y bits inherited from the first session might confuse g-t, which is why i usually switch to a vt first to escape the gnome session) <simo> ok I have gnome-terminal there <simo> so now just use xrandr ? <ajax> yep, same as you did on the full gnome session. <simo> well I got used to do it via control center * simo read xrandr manpage <ajax> you'll want to do 'xrandr --listproviders' on the gnome session, and then replicate that config on the other with --setproviderblah <ajax> i think * robclark has quit (Read error: Connection reset by peer) <simo> ajax: uhm can't I just turn on a display ? * simo tried to tell it to use --right-of but the display is not on I guess <ajax> i honestly don't know how udl devices appear in xrandr <simo> ajax: it appaears as DVI-1-1 <ajax> then sure, light it up. <ajax> i was assuming it was undr the provider interface <simo> ok using explicitly --mode 1366x768 instead of --auto brought it up <simo> ajax: it does the same thing <simo> actually it turned up with the contents last left on in DISPLAY=:0 <simo> moving the mous on top *deletes* those contents replacing them with the default X background but only in a square around the mouse cursor <ajax> and if you drag the terminal window onto the udl display? <simo> it goes there but sometimes when I move it the background fails to update and a ghost terminal is there <ajax> bleh. <simo> interesting <ajax> well, X bug then. <simo> seem to happen only if my mouse touches the right edge <simo> which again has garbage <simo> ie the rightmost 5 pixel columns are just garbage <simo> never properly drawn no matter what <simo> and when the mose touches it <ajax> does that go away if you randr down to 1024x768? <simo> then it "bleeds" all content in until I stop moving <ajax> 13x7 is a bizarre corner case <simo> the display seem to support exclusively 1366x768 <ajax> oh i bet we can fix that... <simo> ajax: can I tell x to not allow window/mouse to touch the rightmost 10 pixels ? <ajax> no <ajax> one moment <simo> becaus as long as I do not tough the right edge I can shake the window as fast as I can and I see no refresh issues <simo> (the terminal windw after I grab it with the mouse) <simo> even crossing back into the main display gives no problems at all <ajax> do you have a 10x7 mode on the main display? <ajax> xrandr --verbose | grep 1024x768 <simo> I can do 1024x768 onm the main display, yes <ajax> ^ if that prints something, grab the hex number inside the parens (0x4c on mine) and do: xrandr --addmode DVI-I-1 0x4c <ajax> and then xrandr --output DVI-I-1 --mode 0x4c <ajax> (this is being slightly abusive but i bet it works) <simo> oh I have 3 modes (diofferent frequencies) <simo> any preference ? <ajax> 65.0MHz ideally, that should be the one that comes out as 60Hz vertical refresh <simo> ajax: now I only have garbage on the usb display :) <simo> I use the 65Hz mode indeed <ajax> hah! okay nevermind that then. <ajax> 13x6 is this stupid corner case because 1366 % 8 != 0 <simo> the display original mode says 60.18*+ when I xrandr <ajax> and for whatever reason people still build hardware that insists on that <simo> I am sure there is some hardware reason for that or something ... <ajax> so the right-edge thing you're seeing i suspect is related to that <simo> ajax: so is this a bug somewhere ? <ajax> and the failure to initially refresh is probably a bug in the X driver for not doing an initial repaint of the screen <simo> it just is strange that if any window touches that edge then stuff gets weird <simo> ajax: it seem to me that *anything* that "touches" that edhe causes the display not to redraw <ajax> why would it be strange that walking off the end of a buffer would do undefined things? <simo> maybe the display does not like it and just drops the request to update its buffer ? <ajax> maybe <simo> ajax: the behavior is consistent with that <simo> and gnome-shell effects perhaps cause the whole screen to redraw more often which may explain why the display drops all those updates <simo> I wonder if I can create a mode that is just a few pixel "narrower" so that I can exclude that edge <simo> ajax: is there a way to tell xrandr to show me modelines for existing modes ? <ajax> xrandr --verbose <simo> ajax: success! <simo> I created a mode 1360 wide <simo> and now it seem I have no more refresh issues <simo> well not exactly <simo> I have slightly different ones, ie now the only area with some issues is the last 6 pixels, which I guess are simply not drawn properly <simo> but the rest works fine
Created attachment 934167 [details] Xorg log file
Additional issue, if I try to rotate the display 90 degrees (dopne via gnome-control-center) then the display seem not working at all (with either native or modified resolution).
FWIW this also happens in Fedora 21
Also in F21 I am not abnle to create a 1360x768 modeline that makes it working anymore. Any help on where to look at the code to handle this would be welcome, I can try out patches or play with the code myself if I am nudged in the right direction.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.