PDA

View Full Version : Fedora 24 AMD64: evdi_painter_crtc_state_notify:362 Painter does not exist!


RobertCochran
08-03-2016, 11:01 PM
(Because it there's not enough room in the title: this is a crosspost from the
Github issues tracker - https://github.com/DisplayLink/evdi/issues/33)

As it says on the title.

OS: Fedora 24 AMD64
Kernel: 4.6.4-301.fc24.x86_64
DisplayLink software: 1.1.65 (Installed from https://github.com/ssaavedra/displaylink-rpm/releases/download/v1.1.65-5/displaylink-1.1.65-5.x86_64.rpm)
Displays: ASUS MB169B+ x2

The ASUS logo is displayed then the screen turns back off when plugged in. No additional screens appear in any RandR tools.

Displays are known good: they work on this machine in Windows 10.
The RPM is known good: the driver works on another machine with Fedora 24 AMD64 and kernel 4.6.4-301.fc24.x86_64.

It doesn't seem to matter if I do one at a time or both of them at once.

The relevant portion of dmesg output:


[ 119.773307] evdi: [D] add_store:195 Increasing device count to 1
[ 119.775968] evdi: [D] evdi_crtc_init:304 drm_crtc_init: 0
[ 119.776347] evdi: [W] evdi_painter_crtc_state_notify:362 Painter does not exist!
[ 119.776359] evdi: [D] evdi_detect:72 Painter is disconnected
[ 119.776373] evdi evdi.0: No connectors reported connected with modes
[ 119.776381] [drm] Cannot find any crtc or sizes - going 1024x768
[ 119.782981] evdi evdi.0: fb1: evdidrmfb frame buffer device
[ 119.782996] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 119.783003] [drm] No driver support for vblank timestamp query.
[ 119.783009] [drm] evdi: evdi_stats_init
[ 119.783034] [drm] Initialized evdi 1.1.65 20160512 on minor 1
[ 119.878077] evdi: [W] evdi_painter_disconnect:462 (dev=0) An unknown connection to ffff88036f437a00 tries to close us
[ 119.878086] evdi: [W] evdi_painter_disconnect:463 - ignoring

RobertCochran
08-04-2016, 10:06 PM
I've done some more digging through the code. My issues appears to be that the
DRM_IOCTL_EVDI_CONNECT isn't being sent to the evdi module in my configuration.
Best I can tell, this indicates an issue in the DisplayLinkManager program.

sky4vip
08-16-2016, 11:18 AM
I have (and reproduce) same issue as above w/ same error in dmesg.

Monitor known good, works in Ubuntu 16.04 as well as Win 10.

Station is a plugable usb 3.0 docking station, monitor is external Dell 2208WFPt

Will update when/if I get to look at referenced rpm source [1] and displaylink reference.

[1] https://github.com/ssaavedra/displaylink-rpm/releases/download/v1.1.65-5/displaylink-1.1.65-5.x86_64.rpm

mlukaszek
08-17-2016, 09:27 AM
It is hard to tell exactly what's happening, but DisplayLinkManager clearly has some problems with connecting to EVDI nodes on your machine - as in, I am certain that a call to evdi_connect fails, but it may even not get to this - our logging is not too verbose by default so can't tell for sure without a repro.

Is it possible that this started since an update of the package? Has it ever worked for you, using a previous version for example?

Note that we are unable to reproduce this with an identical device - running Ubuntu and official package though.

Edit: I managed to upgrade my FC23 installation to FC24 (running 4.6.6) and tried the RPM you linked with two identical ASUS monitors. As you see they worked for me. Obviously my host is different.

2823

Could you try with Ubuntu on your setup for comparison?

If possible I recommend trying with a shorter/better quality USB cable, and/or a connection through a powered hub.

You also mention that the monitors work with Windows. If you use another O/S, it's possible that a firmware package for the monitors is being changed upon connecting - and with these monitors it can take quite long (can be about 30 secs I think), and Linux driver does not show any notifications that this is happening.
Can you connect one of them and keep it connected for longer to be sure that the firmware image is fully flashed to it? The logo should appear for a moment, then the screen turns black during the update, then the logo should reappear for a moment and soon after this the driver should start displaying pixels. If this succeeds, try with the second screen.

Cheers,
Michal

PS: Sorry for a delay, it's a holiday season and things are a bit slower than usual :cool:

RobertCochran
08-18-2016, 12:00 AM
It is hard to tell exactly what's happening, but DisplayLinkManager clearly has some problems with connecting to EVDI nodes on your machine - as in, I am certain that a call to evdi_connect fails, but it may even not get to this - our logging is not too verbose by default so can't tell for sure without a repro.

I have debug printout patches in both evdi and libevdi. In my tests with these versions, the call never happens.


Is it possible that this started since an update of the package? Has it ever worked for you, using a previous version for example?


No, I've only ever used this package. I haven't had my displays long enough to use any prior version.


Edit: I managed to upgrade my FC23 installation to FC24 (running 4.6.6) and tried the RPM you linked with two identical ASUS monitors. As you see they worked for me. Obviously my host is different.

2823


Unsurprising, given my relative lack of luck compared to other people I've had try. :P


Could you try with Ubuntu on your setup for comparison?


I'm willing to try it, but I'm not sure how to go about this. I'm certainly not going to install Ubuntu over top my existing Fedora system. Would booting from a USB image be alright?


If possible I recommend trying with a shorter/better quality USB cable, and/or a connection through a powered hub.


The cables I'm using are the ASUS OEM ones, and they are also the only 3.0 USB Micro cables I own.

I'll try with a powered hub, but I'm not sure what that will do me. Even if it did work, needing a second power socket would kinda suck; I was not anticipating needing a powered hub for this, especially considering I can plug in directly in Windows.

EDIT: Powered hub did not make a difference.


You also mention that the monitors work with Windows. If you use another O/S, it's possible that a firmware package for the monitors is being changed upon connecting - and with these monitors it can take quite long (can be about 30 secs I think), and Linux driver does not show any notifications that this is happening.
Can you connect one of them and keep it connected for longer to be sure that the firmware image is fully flashed to it? The logo should appear for a moment, then the screen turns black during the update, then the logo should reappear for a moment and soon after this the driver should start displaying pixels. If this succeeds, try with the second screen.


I ensured that the flashing had completed (the monitor did exactly as described). No change.


PS: Sorry for a delay, it's a holiday season and things are a bit slower than usual


Eh, slightly unhappy that things have been going slow, but all will be forgiven if we can get things to work.

Thanks for your assistance.

~RobertCochran

sky4vip
08-18-2016, 07:24 PM
eom. will try to follow up later. similar holidays

RobertCochran
08-31-2016, 06:43 PM
Installed Ubuntu 16.04.1 onto a spare HDD, then ensured packages were up to date. Everything worked fine with the latest DisplayLink driver release - all monitors turned on and I was able to achieve a full 3-headed spread.

RobertCochran
09-06-2016, 06:12 PM
I've updated my kernel to the provided 4.7.x series kernel and rebuilt evdi and libevdi from the git repo. I'm still unable to see any additional displays in my randr tools.

RobertCochran
09-13-2016, 09:14 PM
Rebuilt again from the latest evdi sources. Same kernel. Same lack of displays.

Are we making any progress on this?

mlukaszek
09-15-2016, 09:12 AM
We'll soon be releasing a new version of the driver for Ubuntu - maybe this will fix the problems you're seeing.

As a side note - please keep in mind that so far Ubuntu is the only distro we support and test, so with Fedora you're practically on your own - and while the community is great in helping maintain ports to other distros, variety of combinations of different components in the graphics stack may lead to some distinct problems, meaning it's possible things will not work equally well everywhere.

Cheers,
Michal

RobertCochran
09-25-2016, 10:46 PM
The new driver release does not fix my issue.

I'm not going to change OSes for a stupid monitor. I shouldn't *have* to.

As far as I can see, you appear to be the only DisplayLink guy helping out in the
Linux subforum. It sucks, so I understand to a point. Still though:

1) I bought these monitors close to 2 months ago and haven't been able to use them.
2) I have done everything I can reasonably do to fix the problem from my end WRT code.
I looked through and worked out as much as I can of EVDI.
3) But the problem is in the proprietary part. So I can't fix it.
4) This could have been done and over with nearly 2 months ago if I could have fixed it
myself.
5) Now I have to wait on DisplayLink to fix the issue.
6) Support has been abysmal because they only have one freaking developer on the
Linux subforum.

None of that is necessarily /your/ fault; rather, DisplayLink as a whole. I'm not
attempting to single out and flame you in particular. I'm just done dealing with this issue.

This whole experience has been so bad that even *if* I'm able to get my monitors to
work, I'm never buying anything with DisplayLink inside again.

mlukaszek
09-27-2016, 07:18 AM
http://displaylink.org/forum/showthread.php?t=64026&page=5

Some folks are successful on Fedora. Did you try the RPM they prepared based on the latest release?

I still can't see what specific difference you have in your setup making it not compatible. You said that it works with Ubuntu - and we don't officially support any other distro, despite trying to assist in porting where we can. Sorry.

Cheers,
Michal

RobertCochran
10-22-2016, 04:56 AM
I tried the new 10/11 release a few days ago. Exact same thing still.