Hi Devs! On Fri, Jun 9, 2017 at 7:31 PM, Noralf Trønnes <noralf@xxxxxxxxxxx> wrote: > > Den 09.06.2017 22.59, skrev Marco Diego Aurélio Mesquita: >> >> Hi Devs! >> >> On Thu, Jun 8, 2017 at 4:08 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >>> >>> I don't think that using cma for the gm12u320 is a good idea, it will >>> typically be used as a secondary GPU output together with a real GPU >>> extending the desktop by being a prime display output. So for the memory >>> management stuff I would keep the code copied from the udl driver (which >>> we may later split out in a separate helper lib for devices where >>> the framebuffer is in normal system memory and we have some >>> scather-gather >>> capable process copying it to the real device over e.g. USB) >>> >> I got the PL111 driver and stripped all device specific code. Also, I >> added the get_modes and driver usb probe functions from gm12u320. The >> resulting code is available in >> https://gitlab.com/marcodiego/dummy-display-driver . >> >> The driver compiles, loads, identifies the device when I plug it, >> /dev/fb1 is created adequately but it stops there. Gnome monitors tool >> does not see it as a new monitor. What I expected was that it would be >> seen as a new monitor and that I could even activate it. Instead, >> syslog complains: "Cannot find any crtc or sizes". >> >> Anyway, I think this is a first step. My first doubt: where should I >> go from now? What should I change in the driver so that gnome monitors >> tool sees it as a new monitor and I could activate it, even if it >> works as a mere dummy device? >> >> Second doubt is: is this really the simplest/best way? I mean, the >> repaper driver that Emil pointed seems a lot simpler, wouldn't it be >> better to mimic it? How complicated is it to modify the repaper driver >> to build a dummy driver? >> >> By dummy driver, I mean something that gnome monitors tools can >> identify as a new monitor and I can activate it. I hope to reach a >> point where the update or dirty callback is called. From that point on >> it is just a matter of sending the framebuffer through USB the way >> gm12u320 does currently. > > > I guess you have forgotten to replace connector detect, because I > didn't see you use drm_panel in your RFC. > (gm12u320_connector->panel is NULL afaict, so it's always disconnected) > > static enum drm_connector_status gm12u320_connector_detect(struct > drm_connector > *connector, bool force) > { > - struct gm12u320_drm_connector *gm12u320_connector = > - to_gm12u320_connector(connector); > - > - return (gm12u320_connector->panel ? > - connector_status_connected : > - connector_status_disconnected); > + if (drm_device_is_unplugged(connector->dev)) > + return connector_status_disconnected; > + > + return connector_status_connected; > } > > I applied this change and now gnome monitors tool identifies it as another monitor, thanks Noralf! There are still some problems: when I activate it, gnome complains "could not set configuration for CRTC 284". I still don't know what causes this. Any idea? Other problem I get is that the device is spontaneously disconnected after some time. I'm not sure what causes this, but I think it happens because it receives no data after an amount of time. On the udl-based driver, a workqueue is used to periodically send some data to the device. Is there any problem using the same approach here? I mean, won't using a workqueue to periodically send some data to the device bring any conflict? If not, I'll start porting the code related to the workqueue from the udl-based driver to the pl111-based driver. That will probably improve the behavior of the device. Once I get it behaving properly, my next step will be to finally try to update the framebuffer of the device and get it to show something. Does this approach seem sound? _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
