From: Alexey.Brodkin@synopsys.com (Alexey Brodkin)
To: linux-snps-arc@lists.infradead.org
Subject: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Date: Mon, 4 Dec 2017 13:16:48 +0000 [thread overview]
Message-ID: <1512393408.4977.44.camel@synopsys.com> (raw)
In-Reply-To: <86238def-82be-2ad1-63d0-b9a8dbf83db6@synopsys.com>
Hi Jose,
On Mon, 2017-12-04@11:50 +0000, Jose Abreu wrote:
> Hi Alexey,
>
> On 04-12-2017 11:32, Alexey Brodkin wrote:
> >
> > My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX)
> > and it cannot use DRI video card natively. Is that correct?
> >
> >
>
> Xserver can use DRI directly, you need to enable modesetting
> driver in Xorg config or use the designated driver for your card
> (if there is any).
Ok that makes sense. I didn't think about generic modesetting driver for Xserver.
And that indeed works. This is my xorg.conf:
----------------------->8----------------------
# cat /etc/X11/xorg.conf?
Section "Device"
????????Identifier??????"Driver0"
????????Screen??????????0
????????Driver??????????"modesetting"
????????Option??????????"kmsdev" "/dev/dri/card1"
EndSection
----------------------->8----------------------
I do see xclock is rendered fine.
Now I guess is getting closer to what I really need :)
In the end I wanted to get 3D rendered by Vivante GPU
to be displayed on UDL. My assumption was very simple - if IMX-DRM+Etnaviv
work fine it should be straight-forward to swap IMX-DRM bitstreamer with UDL
and we're golden.
That might be more a question to Lucas now.
I use xorg.conf as found here:
http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/tree/conf/xorg-sample.conf?h=unstable-devel
That's what it has:
----------------------->8----------------------
Section "Device"
Identifier "Driver0"
Screen 0
Driver "armada"
# Support hotplugging displays?
# Option "Hotplug" "TRUE"
# Support hardware cursor if available?
# Option "HWCursor" "TRUE"
# Use GPU acceleration?
# Option "UseGPU" "TRUE"
# Provide Xv interfaces?
# Option "XvAccel" "TRUE"
# Prefer overlay for Xv (TRUE for armada-drm, FALSE for imx-drm)
# Option "XvPreferOverlay" "TRUE"
# Which accelerator module to load (automatically found if commented out)
# Option "AccelModule" "etnadrm_gpu"
# Option "AccelModule" "etnaviv_gpu"
# Support DRI2 interfaces?
# Option "DRI" "TRUE"
EndSection
----------------------->8----------------------
Indeed I uncommented all the lines and then it allows to see
for example glmark2-es2 working on Wandboard (that's exactly where
"imx-drm + etnaviv" combo is used).
But if I swap "imx-drm" to "udl" I don't see anything on my screen
(connected via UDL) even though Xserver seems to really start claiming the screen
(so I see it becomes black, effectively overriding whatever was there before) and
glmark benchmark prints results.
Maybe I'm missing some additional glue for UDL in "xf86-video-armada" except the simple one:
----------------------->8----------------------
--- a/src/armada_module.c
+++ b/src/armada_module.c
@@ -26,7 +26,7 @@
?#define ARMADA_NAME????????????"armada"
?#define ARMADA_DRIVER_NAME?????"armada"
?
-#define DRM_MODULE_NAMES???????"armada-drm", "imx-drm"
+#define DRM_MODULE_NAMES???????"armada-drm", "imx-drm", "udl"
?#define DRM_DEFAULT_BUS_ID?????NULL
?
?static const char *drm_module_names[] = { DRM_MODULE_NAMES };
@@ -43,6 +43,11 @@ static SymTabRec ipu_chipsets[] = {
????????{ -1, NULL }
?};
?
+static SymTabRec udl_chipsets[] = {
+???????{??0, "UDL" },
+???????{ -1, NULL }
+};
+
?static const OptionInfoRec * const options[] = {
????????armada_drm_options,
????????common_drm_options,
@@ -115,6 +120,8 @@ static void armada_identify(int flags)
??????????????????????????armada_chipsets);
????????xf86PrintChipsets(ARMADA_NAME, "Support for Freescale IPU",
??????????????????????????ipu_chipsets);
+???????xf86PrintChipsets(ARMADA_NAME, "Support DisplayLink USB2.0",
+?????????????????????????udl_chipsets);
?}
----------------------->8----------------------
-Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "l.stach@pengutronix.de" <l.stach@pengutronix.de>,
Jose Abreu <Jose.Abreu@synopsys.com>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"airlied@gmail.com" <airlied@gmail.com>,
"airlied@redhat.com" <airlied@redhat.com>,
"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]
Date: Mon, 4 Dec 2017 13:16:48 +0000 [thread overview]
Message-ID: <1512393408.4977.44.camel@synopsys.com> (raw)
In-Reply-To: <86238def-82be-2ad1-63d0-b9a8dbf83db6@synopsys.com>
Hi Jose,
On Mon, 2017-12-04 at 11:50 +0000, Jose Abreu wrote:
> Hi Alexey,
>
> On 04-12-2017 11:32, Alexey Brodkin wrote:
> >
> > My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX)
> > and it cannot use DRI video card natively. Is that correct?
> >
> >
>
> Xserver can use DRI directly, you need to enable modesetting
> driver in Xorg config or use the designated driver for your card
> (if there is any).
Ok that makes sense. I didn't think about generic modesetting driver for Xserver.
And that indeed works. This is my xorg.conf:
----------------------->8----------------------
# cat /etc/X11/xorg.conf
Section "Device"
Identifier "Driver0"
Screen 0
Driver "modesetting"
Option "kmsdev" "/dev/dri/card1"
EndSection
----------------------->8----------------------
I do see xclock is rendered fine.
Now I guess is getting closer to what I really need :)
In the end I wanted to get 3D rendered by Vivante GPU
to be displayed on UDL. My assumption was very simple - if IMX-DRM+Etnaviv
work fine it should be straight-forward to swap IMX-DRM bitstreamer with UDL
and we're golden.
That might be more a question to Lucas now.
I use xorg.conf as found here:
http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/tree/conf/xorg-sample.conf?h=unstable-devel
That's what it has:
----------------------->8----------------------
Section "Device"
Identifier "Driver0"
Screen 0
Driver "armada"
# Support hotplugging displays?
# Option "Hotplug" "TRUE"
# Support hardware cursor if available?
# Option "HWCursor" "TRUE"
# Use GPU acceleration?
# Option "UseGPU" "TRUE"
# Provide Xv interfaces?
# Option "XvAccel" "TRUE"
# Prefer overlay for Xv (TRUE for armada-drm, FALSE for imx-drm)
# Option "XvPreferOverlay" "TRUE"
# Which accelerator module to load (automatically found if commented out)
# Option "AccelModule" "etnadrm_gpu"
# Option "AccelModule" "etnaviv_gpu"
# Support DRI2 interfaces?
# Option "DRI" "TRUE"
EndSection
----------------------->8----------------------
Indeed I uncommented all the lines and then it allows to see
for example glmark2-es2 working on Wandboard (that's exactly where
"imx-drm + etnaviv" combo is used).
But if I swap "imx-drm" to "udl" I don't see anything on my screen
(connected via UDL) even though Xserver seems to really start claiming the screen
(so I see it becomes black, effectively overriding whatever was there before) and
glmark benchmark prints results.
Maybe I'm missing some additional glue for UDL in "xf86-video-armada" except the simple one:
----------------------->8----------------------
--- a/src/armada_module.c
+++ b/src/armada_module.c
@@ -26,7 +26,7 @@
#define ARMADA_NAME "armada"
#define ARMADA_DRIVER_NAME "armada"
-#define DRM_MODULE_NAMES "armada-drm", "imx-drm"
+#define DRM_MODULE_NAMES "armada-drm", "imx-drm", "udl"
#define DRM_DEFAULT_BUS_ID NULL
static const char *drm_module_names[] = { DRM_MODULE_NAMES };
@@ -43,6 +43,11 @@ static SymTabRec ipu_chipsets[] = {
{ -1, NULL }
};
+static SymTabRec udl_chipsets[] = {
+ { 0, "UDL" },
+ { -1, NULL }
+};
+
static const OptionInfoRec * const options[] = {
armada_drm_options,
common_drm_options,
@@ -115,6 +120,8 @@ static void armada_identify(int flags)
armada_chipsets);
xf86PrintChipsets(ARMADA_NAME, "Support for Freescale IPU",
ipu_chipsets);
+ xf86PrintChipsets(ARMADA_NAME, "Support DisplayLink USB2.0",
+ udl_chipsets);
}
----------------------->8----------------------
-Alexey
next prev parent reply other threads:[~2017-12-04 13:16 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 11:32 UDL's fbdev doesn't work for user-space apps Alexey Brodkin
2017-12-04 11:32 ` Alexey Brodkin
2017-12-04 11:50 ` Jose Abreu
2017-12-04 11:50 ` Jose Abreu
2017-12-04 11:50 ` Jose Abreu
2017-12-04 13:16 ` Alexey Brodkin [this message]
2017-12-04 13:16 ` xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps] Alexey Brodkin
2017-12-04 14:02 ` Jose Abreu
2017-12-04 14:02 ` Jose Abreu
2017-12-04 14:02 ` Jose Abreu
2017-12-04 14:53 ` Alexey Brodkin
2017-12-04 14:53 ` Alexey Brodkin
2017-12-04 15:55 ` Jose Abreu
2017-12-04 15:55 ` Jose Abreu
2017-12-04 15:55 ` Jose Abreu
2017-12-04 16:00 ` Alexey Brodkin
2017-12-04 16:00 ` Alexey Brodkin
2017-12-04 17:24 ` Jose Abreu
2017-12-04 17:24 ` Jose Abreu
2017-12-04 17:29 ` Alexey Brodkin
2017-12-04 17:29 ` Alexey Brodkin
2017-12-05 10:39 ` Jose Abreu
2017-12-05 10:39 ` Jose Abreu
2017-12-05 10:39 ` Jose Abreu
2017-12-05 11:53 ` Alexey Brodkin
2017-12-05 11:53 ` Alexey Brodkin
2017-12-05 11:53 ` Alexey Brodkin
2017-12-05 12:26 ` Jose Abreu
2017-12-05 12:26 ` Jose Abreu
2017-12-05 12:26 ` Jose Abreu
2017-12-05 14:47 ` Alexey Brodkin
2017-12-05 14:47 ` Alexey Brodkin
2017-12-04 17:52 ` Emil Velikov
2017-12-04 17:52 ` Emil Velikov
2017-12-04 17:52 ` Emil Velikov
2017-12-09 17:20 ` UDL's fbdev doesn't work for user-space apps Pavel Machek
2017-12-09 17:20 ` Pavel Machek
2017-12-09 17:20 ` Pavel Machek
2017-12-12 19:48 ` Alexey Brodkin
2017-12-12 19:48 ` Alexey Brodkin
2017-12-12 21:12 ` Pavel Machek
2017-12-12 21:12 ` Pavel Machek
2017-12-12 21:12 ` Pavel Machek
2017-12-12 21:58 ` Noralf Trønnes
2017-12-12 21:58 ` Noralf Trønnes
2017-12-12 21:58 ` Noralf Trønnes
2017-12-13 21:53 ` Alexey Brodkin
2017-12-13 21:53 ` Alexey Brodkin
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=1512393408.4977.44.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--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.