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
next prev parent 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: linkBe 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.