From: Alexey.Brodkin@synopsys.com (Alexey Brodkin)
To: linux-snps-arc@lists.infradead.org
Subject: UDL's fbdev doesn't work for user-space apps
Date: Mon, 4 Dec 2017 11:32:57 +0000 [thread overview]
Message-ID: <1512387175.4977.24.camel@synopsys.com> (raw)
Hello,
I'm trying to use DisplayLink USB2.0-to-HDMI adapter as the one and only
video output and I want to get Xserver working on top of that.
I'm not very familiar with all the parts of Linux GPU/video stack
(especially its user-space counterpart) so my assumptions might be wrong
in that case please correct me.
My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX)
and it cannot use DRI video card natively. Is that correct?
So to get /ded/fb0 with UDL I just enabled CONFIG_DRM_UDL & CONFIG_DRM_FBDEV_EMULATION.
That gave me boot console on HDMI screen and I was full of expectations.
But when I tried to use /dev/fb0 from whatever user-space app nothing got
displayed on the screen... as well as no error messages appeared.
After?eyeballing at UDL code (especially in comparison with QXC which uses deferredio
as well) I noticed that in UDL fb_deferred_io_init() is called from udl_fb_open(),
i.e. .fb_open call-back (in other words every time user-space app opens /dev/fb0)
while in QXC this is done only once and much earlier in?qxlfb_create(), which is
called with .fb_probe call-back. So moved fb_deferred_io_init() in UDL driver from
udl_fb_open() to?udlfb_create() which is also called from .fb_probe.
With that change I finally got video output via fbdev from user-space app,
but only on the first run. The next attempt to run inevitably ends with
kernel crash showing the following stack-trace (having half of the new screen
rendered on display):
------------------------>8-------------------------
Stack Trace:
? udl_handle_damage+0x48/0x210
? udl_crtc_mode_set+0x6ee/0x754
? drm_crtc_helper_set_mode+0x25e/0x438
? drm_crtc_helper_set_config+0x6d6/0x814
? __drm_mode_set_config_internal+0x48/0xc8
? drm_mode_setcrtc+0x320/0x478
? drm_ioctl+0x22c/0x3e4
? SyS_ioctl+0xa4/0x8cc
? EV_Trap+0x108/0x10c
random: crng init done
------------------------>8-------------------------
I'm wondering if UDL driver (its DRM flavor) was ever tested for
fbdev in user-space? If so and it really works for somebody
maybe I'm doing something terribly wrong - in that case any comments
are very welcome.
One interesting note: it seems like pure DRI stuff works like a charm.
I may run kmscube perfectly fine without any changes whatsoever and do it
many times in a row.
Thanks in advance,
Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "airlied@gmail.com" <airlied@gmail.com>
Cc: "airlied@redhat.com" <airlied@redhat.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"hshi@chromium.org" <hshi@chromium.org>,
"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
"tutankhamen@chromium.org" <tutankhamen@chromium.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: UDL's fbdev doesn't work for user-space apps
Date: Mon, 4 Dec 2017 11:32:57 +0000 [thread overview]
Message-ID: <1512387175.4977.24.camel@synopsys.com> (raw)
Hello,
I'm trying to use DisplayLink USB2.0-to-HDMI adapter as the one and only
video output and I want to get Xserver working on top of that.
I'm not very familiar with all the parts of Linux GPU/video stack
(especially its user-space counterpart) so my assumptions might be wrong
in that case please correct me.
My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX)
and it cannot use DRI video card natively. Is that correct?
So to get /ded/fb0 with UDL I just enabled CONFIG_DRM_UDL & CONFIG_DRM_FBDEV_EMULATION.
That gave me boot console on HDMI screen and I was full of expectations.
But when I tried to use /dev/fb0 from whatever user-space app nothing got
displayed on the screen... as well as no error messages appeared.
After eyeballing at UDL code (especially in comparison with QXC which uses deferredio
as well) I noticed that in UDL fb_deferred_io_init() is called from udl_fb_open(),
i.e. .fb_open call-back (in other words every time user-space app opens /dev/fb0)
while in QXC this is done only once and much earlier in qxlfb_create(), which is
called with .fb_probe call-back. So moved fb_deferred_io_init() in UDL driver from
udl_fb_open() to udlfb_create() which is also called from .fb_probe.
With that change I finally got video output via fbdev from user-space app,
but only on the first run. The next attempt to run inevitably ends with
kernel crash showing the following stack-trace (having half of the new screen
rendered on display):
------------------------>8-------------------------
Stack Trace:
udl_handle_damage+0x48/0x210
udl_crtc_mode_set+0x6ee/0x754
drm_crtc_helper_set_mode+0x25e/0x438
drm_crtc_helper_set_config+0x6d6/0x814
__drm_mode_set_config_internal+0x48/0xc8
drm_mode_setcrtc+0x320/0x478
drm_ioctl+0x22c/0x3e4
SyS_ioctl+0xa4/0x8cc
EV_Trap+0x108/0x10c
random: crng init done
------------------------>8-------------------------
I'm wondering if UDL driver (its DRM flavor) was ever tested for
fbdev in user-space? If so and it really works for somebody
maybe I'm doing something terribly wrong - in that case any comments
are very welcome.
One interesting note: it seems like pure DRI stuff works like a charm.
I may run kmscube perfectly fine without any changes whatsoever and do it
many times in a row.
Thanks in advance,
Alexey
next reply other threads:[~2017-12-04 11:32 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 11:32 Alexey Brodkin [this message]
2017-12-04 11:32 ` UDL's fbdev doesn't work for user-space apps 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 ` xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps] Alexey Brodkin
2017-12-04 13:16 ` 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=1512387175.4977.24.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.