All of lore.kernel.org
 help / color / mirror / Atom feed
From: daniel.vetter@ffwll.ch (Daniel Vetter)
To: linux-snps-arc@lists.infradead.org
Subject: DRM_UDL and GPU under Xserver
Date: Thu, 5 Apr 2018 08:18:29 +0200	[thread overview]
Message-ID: <CAKMK7uG1_B-r+XxVzMusMOBd=udhp8EdL59f375AG5+MO02O4g@mail.gmail.com> (raw)
In-Reply-To: <1522872371.4851.106.camel@synopsys.com>

On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hello,
>
> We're trying to use DisplayLink USB2-to-HDMI adapter to render GPU-accelerated graphics.
> Hardware setup is as simple as a devboard + DisplayLink adapter.
> Devboards we use for this experiment are:
>  * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or
>  * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as well)
>
> I'm sure any other board with DRM supported GPU will work, those we just used
> as the very recent Linux kernels could be easily run on them both.
>
> Basically the problem is UDL needs to be explicitly notified about new data
> to be rendered on the screen compared to typical bit-streamers that infinitely
> scan a dedicated buffer in memory.
>
> In case of UDL there're just 2 ways for this notification:
>  1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs->page_flip()
>  2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs->dirty()
>
> But neither of IOCTLs happen when we run Xserver with xf86-video-armada driver
> (see http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/log/?h=unstable-devel).
>
> Is it something missing in Xserver or in UDL driver?

Use the -modesetting driverr for UDL, that one works correctly.
Kernel-driver specific X drivers are kinda deprecated, and stuff like
this (and other bugfixes and improvements that don't propagate around)
are the reason for that.
-Daniel

>
> Regards,
> Alexey
>
>
>
>
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"airlied@redhat.com" <airlied@redhat.com>,
	"alexander.deucher@amd.com" <alexander.deucher@amd.com>,
	"daniel.vetter@intel.com" <daniel.vetter@intel.com>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>
Subject: Re: DRM_UDL and GPU under Xserver
Date: Thu, 5 Apr 2018 08:18:29 +0200	[thread overview]
Message-ID: <CAKMK7uG1_B-r+XxVzMusMOBd=udhp8EdL59f375AG5+MO02O4g@mail.gmail.com> (raw)
In-Reply-To: <1522872371.4851.106.camel@synopsys.com>

On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hello,
>
> We're trying to use DisplayLink USB2-to-HDMI adapter to render GPU-accelerated graphics.
> Hardware setup is as simple as a devboard + DisplayLink adapter.
> Devboards we use for this experiment are:
>  * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or
>  * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as well)
>
> I'm sure any other board with DRM supported GPU will work, those we just used
> as the very recent Linux kernels could be easily run on them both.
>
> Basically the problem is UDL needs to be explicitly notified about new data
> to be rendered on the screen compared to typical bit-streamers that infinitely
> scan a dedicated buffer in memory.
>
> In case of UDL there're just 2 ways for this notification:
>  1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs->page_flip()
>  2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs->dirty()
>
> But neither of IOCTLs happen when we run Xserver with xf86-video-armada driver
> (see http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/log/?h=unstable-devel).
>
> Is it something missing in Xserver or in UDL driver?

Use the -modesetting driverr for UDL, that one works correctly.
Kernel-driver specific X drivers are kinda deprecated, and stuff like
this (and other bugfixes and improvements that don't propagate around)
are the reason for that.
-Daniel

>
> Regards,
> Alexey
>
>
>
>
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-04-05  6:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-04 20:06 DRM_UDL and GPU under Xserver Alexey Brodkin
2018-04-04 20:06 ` Alexey Brodkin
2018-04-05  6:18 ` Daniel Vetter [this message]
2018-04-05  6:18   ` Daniel Vetter
2018-04-05  7:16   ` Alexey Brodkin
2018-04-05  7:16     ` Alexey Brodkin
2018-04-05  9:32     ` Daniel Vetter
2018-04-05  9:32       ` Daniel Vetter
2018-04-05 10:10       ` Jose Abreu
2018-04-05 10:10         ` Jose Abreu
2018-04-05 10:29       ` Lucas Stach
2018-04-05 10:29         ` Lucas Stach
2018-04-05 10:59         ` Daniel Vetter
2018-04-05 10:59           ` Daniel Vetter
2018-04-05 11:10           ` Alexey Brodkin
2018-04-05 11:10             ` Alexey Brodkin
2018-04-05 13:44             ` Daniel Vetter
2018-04-05 13:44               ` Daniel Vetter
2018-04-05 18:39               ` Alexey Brodkin
2018-04-05 18:39                 ` Alexey Brodkin
2018-04-09  8:31                 ` Daniel Vetter
2018-04-09  8:31                   ` Daniel Vetter
2018-04-09  8:55                   ` Alexey Brodkin
2018-04-09  8:55                     ` Alexey Brodkin
2018-04-09  9:17                     ` Daniel Vetter
2018-04-09  9:17                       ` Daniel Vetter
2018-04-09  9:45                       ` Alexey Brodkin
2018-04-09  9:45                         ` Alexey Brodkin
2018-04-13 15:52                         ` Daniel Vetter
2018-04-13 15:52                           ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKMK7uG1_B-r+XxVzMusMOBd=udhp8EdL59f375AG5+MO02O4g@mail.gmail.com' \
    --to=daniel.vetter@ffwll.ch \
    --cc=linux-snps-arc@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.