Re: UDL's fbdev doesn't work for user-space apps

[Alexey Brodkin]

Hi Noralf,

On Tue, 2017-12-12 at 22:58 +0100, Noralf Trønnes wrote:
> Den 04.12.2017 12.32, skrev Alexey Brodkin:
> > 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.
> 
> udl uses shmem buffers which doesn't work with fbdev deferred io.
> They fight over page->lru and page->mapping. See this commit:
> drm/udl: disable fb_defio by default
> 677d23b70bf949f75746c80cbae92c233c6b5e2a

Well that's interesting indeed, but IMHO that's not the most important
problem with UDL as of now since DRI-aware apps and Xserver stuff work
fine with /dev/dri/cardX. What bothers me is some problem [probably] with
export of its DMA buffers, so Vivante GPU does render stuff but it is not 
displayed
on the screen... in absense of error messages I'd conclude that the GPU
just renders to some virtuall addresses which are not mapped to UDL's
"frame-buffers". And it's not about improper handling of caches - I tried
with data caches disabled but still to no avail :(

-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UDL's fbdev doesn't work for user-space apps

[Alexey Brodkin]

Hi Pavel,

On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote:
> On Mon 2017-12-04 11:50:40, 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).
> 
> Still, dev/fb1 should work.

Agree, but it doesn't :)
Even on completely different architectures (ARC and ARM).

> Can be tested using dd, even :-)

Most probably so but not in case of UDL as of today :(
I mean as long as it does't work dd etc make no sense.

-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UDL's fbdev doesn't work for user-space apps

[Noralf Trønnes]

Den 04.12.2017 12.32, skrev Alexey Brodkin:

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.


udl uses shmem buffers which doesn't work with fbdev deferred io.
They fight over page->lru and page->mapping. See this commit:
drm/udl: disable fb_defio by default
677d23b70bf949f75746c80cbae92c233c6b5e2a

Noralf.


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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UDL's fbdev doesn't work for user-space apps

[Pavel Machek]

On Tue 2017-12-12 19:48:05, Alexey Brodkin wrote:
> Hi Pavel,
> 
> On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote:
> > On Mon 2017-12-04 11:50:40, 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).
> > 
> > Still, dev/fb1 should work.
> 
> Agree, but it doesn't :)
> Even on completely different architectures (ARC and ARM).

Yeah, would be nice to get it fixed :-). I remember it did not work
for me, either, and .. that's some time ago.

Architecture probably plays no role there.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UDL's fbdev doesn't work for user-space apps

[Pavel Machek]

On Mon 2017-12-04 11:50:40, 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).

Still, dev/fb1 should work. Can be tested using dd, even :-)

Best regards,
Pavel
> 
> e.g.:
> 
> Section "Device"
> Identifier "Card0"
> Driver "modesetting"
> Option "kmsdev" "/dev/dri/card0"
> Option "SWcursor" "true"
> BusID "PCI:X:X:X"
> EndSection
> 
> Best Regards,
> Jose Miguel Abreu

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Alexey Brodkin]

Hi Jose,

On Tue, 2017-12-05 at 10:39 +, Jose Abreu wrote:
> Hi Alexey,
> 
> On 04-12-2017 17:29, Alexey Brodkin wrote:
> > 
> > 
> > Indeed, in case of kmscube etnaviv is a renderer while UDL
> > outputs the picture on the screen.
> 
> Thats nice :)
> 
> Ok, from your logs I was not able to see anything wrong. X server
> does not error exit and Prime seems to be working in DRM ...
> 
> Lets try one more thing: Enable all debug in DRM (drm.debug=0x3f)
> and try to correlate the log with the actions. i.e.
> 
> [boot]
> [log]
> [x start]
> [log]
> [xclock start]
> [log]
> [glmark2-es2 start]
> [log]

I think I have something like that.

Below are extracts which show at least one difference I was able to find.
And that difference is presence of "[drm:udl_drm_gem_mmap] flags = 0x1"
in case of Xserver only.

kmscube:
-->8---
[drm:drm_crtc_helper_set_config] encoder changed, full mode switch
[drm:drm_crtc_helper_set_config] crtc changed, full mode switch
[drm:drm_crtc_helper_set_config] [CONNECTOR:30:DVI-I-1] to [CRTC:28:crtc-0]
[drm:drm_crtc_helper_set_config] attempting to set mode from userspace
[drm:drm_mode_debug_printmodeline] Modeline 44:"1920x1080" 60 148500 1920 2008 
2052 2200 1080 1084 1089 1125 0x48 0x5
[drm:drm_crtc_helper_set_mode] [CRTC:28:crtc-0]
[drm:drm_crtc_helper_set_mode] [ENCODER:29:TMDS-29] set [MODE:44:1920x1080]
[drm] write mode info 153
[drm:drm_crtc_helper_set_config] Setting connector DPMS state to on
[drm:drm_crtc_helper_set_config][CONNECTOR:30:DVI-I-1] set DPMS on
[drm:udl_attach_dma_buf] [DEV:soc:gpu-subsystem] size:8355840
[drm:udl_map_dma_buf] [DEV:soc:gpu-subsystem] size:8355840 dir=0
etnaviv-gpu f009.gpu: virt 7104 phys 0x free 0x1ec0
stream link to 0x00a8 @ 0x2000 71042000
-->8---

X:
-->8---
[drm:udl_drm_gem_mmap] flags = 0x1
[drm:drm_mode_addfb] [FB:43]
[drm:drm_mode_setcrtc] [CRTC:28:crtc-0]
[drm:drm_mode_setcrtc] [CONNECTOR:30:DVI-I-1]
[drm:drm_crtc_helper_set_config] 
[drm:drm_crtc_helper_set_config] [CRTC:28:crtc-0] [FB:43] #connectors=1 (x y) 
(0 0)
[drm:drm_crtc_helper_set_config] crtc has no fb, full mode set
[drm:drm_crtc_helper_set_config] connector dpms not on, full mode switch
[drm:drm_crtc_helper_set_config] encoder changed, full mode switch
[drm:drm_crtc_helper_set_config] crtc changed, full mode switch
[drm:drm_crtc_helper_set_config] [CONNECTOR:30:DVI-I-1] to [CRTC:28:crtc-0]
[drm:drm_crtc_helper_set_config] attempting to set mode from userspace
[drm:drm_mode_debug_printmodeline] Modeline 44:"" 0 148500 1920 2008 2052 2200 
1080 1084 1089 1125 0x0 0x5
[drm:drm_crtc_helper_set_mode] [CRTC:28:crtc-0]
[drm:drm_crtc_helper_set_mode] [ENCODER:29:TMDS-29] set [MODE:44:]
[drm] write mode info 153
[drm:drm_crtc_helper_set_config] Setting connector DPMS state to on
[drm:drm_crtc_helper_set_config][CONNECTOR:30:DVI-I-1] set DPMS on
[drm] write mode info 153
[drm:udl_attach_dma_buf] [DEV:soc:gpu-subsystem] size:8298496
[drm:udl_map_dma_buf] [DEV:soc:gpu-subsystem] size:8298496 dir=0
etnaviv-gpu f009.gpu: virt 7104 phys 0x free 0x1ec0
stream link to 0x01e8 @ 0x2000 71042000
-->8---

> If that does not give any more info then maybe someone with
> better understanding of etnaviv, UDL and X can help


From my note above about udl_drm_gem_mmap() being only used in case of Xserver
I barely may conclude anything. Given my lack of knowledge of DRM guts
especially
when it comes to complicated cases with DMA buffer exports/imports I cannot say
immediately if that's just improper implementation of
udl_drm_gem_mmap() or not.
Even though I do see some differences between implementation of 
file_operations->mmap()
callback in UDL and
say exynos_drm_gem_mmap() or qxl_mmap() it's not clear
why this and that implementation was done.

> (maybe cc X devel list also ...)

Well at this point I think its purely a UDL driver problem because if we swap 
UDL to
imx-drm on Wandboard everything works perfectly fine!

-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Alexey Brodkin]

Hi Jose,

On Tue, 2017-12-05 at 12:26 +, Jose Abreu wrote:
> On 05-12-2017 11:53, Alexey Brodkin wrote:
> > 
> > 
> > From my note above about udl_drm_gem_mmap() being only used in case of 
> > Xserver
> > I barely may conclude anything. Given my lack of knowledge of DRM guts
> > especially
> > when it comes to complicated cases with DMA buffer exports/imports I cannot 
> > say
> > immediately if that's just improper implementation of
> > udl_drm_gem_mmap() or not.
> > Even though I do see some differences between implementation of 
> > file_operations->mmap()
> > callback in UDL and
> > say exynos_drm_gem_mmap() or qxl_mmap() it's not clear
> > why this and that implementation was done.
> 
> Oh, I've seen this before. This is the same thing that arcpgu
> used to do in the mmap callback! Please comment out the call to
> update_vm_cache_attr() in the mmap callback and check if it works.

Actually I did it as the first thing when I spotted it in udl_drm_gem_mmap().
But that made no difference at all :(

-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

On 05-12-2017 11:53, Alexey Brodkin wrote:
>
> From my note above about udl_drm_gem_mmap() being only used in case of Xserver
> I barely may conclude anything. Given my lack of knowledge of DRM guts
> especially
> when it comes to complicated cases with DMA buffer exports/imports I cannot 
> say
> immediately if that's just improper implementation of
> udl_drm_gem_mmap() or not.
> Even though I do see some differences between implementation of 
> file_operations->mmap()
> callback in UDL and
> say exynos_drm_gem_mmap() or qxl_mmap() it's not clear
> why this and that implementation was done.

Oh, I've seen this before. This is the same thing that arcpgu
used to do in the mmap callback! Please comment out the call to
update_vm_cache_attr() in the mmap callback and check if it works.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

Hi Alexey,

On 04-12-2017 17:29, Alexey Brodkin wrote:
>
> Indeed, in case of kmscube etnaviv is a renderer while UDL
> outputs the picture on the screen.

Thats nice :)

Ok, from your logs I was not able to see anything wrong. X server
does not error exit and Prime seems to be working in DRM ...

Lets try one more thing: Enable all debug in DRM (drm.debug=0x3f)
and try to correlate the log with the actions. i.e.

[boot]
[log]
[x start]
[log]
[xclock start]
[log]
[glmark2-es2 start]
[log]

If that does not give any more info then maybe someone with
better understanding of etnaviv, UDL and X can help (maybe cc X
devel list also ...)

Best Regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Alexey Brodkin]

Hi Jose,

On Mon, 2017-12-04 at 17:24 +, Jose Abreu wrote:
> On 04-12-2017 16:00, Alexey Brodkin wrote:
> > 
> > [30.763] (II) armada(0): etnaviv: Xv: using YUY2 format intermediate 
> > YUV target
> > 
> 
> I'm wondering if this means that target format for UDL is YUV ...
> 
> But anyway, I revisited your first email and noticed that you
> said kmscube runs fine. Is this using etnaviv as renderer?

Indeed, in case of kmscube etnaviv is a renderer while UDL
outputs the picture on the screen.

> And
> you also said X is claiming the screen but nothing appears ...
> which X client are you using to test this?

Well it might be seen from my full log.
I just start X with "X&" command and then
execute things like "xclock".

So not sure who is a client in that case.

-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Alexey Brodkin]

Hi Jose,

On Mon, 2017-12-04 at 14:02 +, Jose Abreu wrote:
> On 04-12-2017 13:16, Alexey Brodkin wrote:
> > 
> > Option  "kmsdev" "/dev/dri/card1"
> 
> Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and
> if you don't specify the busID it will fallback for the first
> card that matches "armada-drm" or "imx-drm" or "udl".
> 
> > 
> > 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.
> > 
> > 
> 
> Xorg.log can help confirm if everything is ok.

That's xorg.conf:
--->8--
# cat /etc/X11/xorg.conf 
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--

Full log you may find below.

-Alexey


Linux version 4.14.2-8-g95be6f762b7f-dirty (abrodkin@abrodkin-7440l) (gcc 
version 7.1.1 20170710 (ARCv2 ISA Linux uClibc toolchain 2017.09-rc1))
#68 SMP PREEMPT Mon Dec 4 16:12:46 MSK 2017
Memory @ 8000 [1024M] 
OF: fdt: Machine model: snps,hsdk
earlycon: uart8250 at MMIO32 0xf0005000 (options '115200n8')
bootconsole [uart8250] enabled
archs-intc  : 2 priority levels (default 1) FIRQ (not used)

IDENTITY: ARCVER [0x52] ARCNUM [0x0] CHIPID [ 0x0]
processor [0]   : ARC HS38 R2.1 (ARCv2 ISA) 
Timers  : Timer0 Timer1 RTC [UP 64-bit] GFRC [SMP 64-bit] 
ISA Extn: atomic ll64 unalign (not used)
: mpy[opt 9] div_rem norm barrel-shift swap minmax swape
BPU : full match, cache:2048, Predict Table:16384
MMU [v4]: 8k PAGE, 2M Super Page (not used) JTLB 1024 (256x4), uDTLB 8, 
uITLB 4, PAE40 (not used) 
I-Cache : 64K, 4way/set, 64B Line, VIPT aliasing
D-Cache : 64K, 2way/set, 64B Line, PIPT
SLC : 512K, 128B Line
Peripherals : 0xf000, IO-Coherency (disabled) 
Vector Table: 0x9000
FPU : SP DP 
DEBUG   : ActionPoint smaRT RTT 
OS ABI [v4] : 64-bit data any register aligned
Extn [SMP]  : ARConnect (v2): 4 cores with IPI IDU DEBUG GFRC
Enable CONFIG_ARC_HAS_ACCL_REGS for working apps
On node 0 totalpages: 131072
free_area_init_node: node 0, pgdat 91cf1080, node_mem_map bfb8
  Normal zone: 576 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 131072 pages, LIFO batch:15
random: fast init done
percpu: Embedded 7 pages/cpu @bfb1c000 s25088 r8192 d24064 u57344
pcpu-alloc: s25088 r8192 d24064 u57344 alloc=7*8192
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
Built 1 zonelists, mobility grouping on.  Total pages: 130496
Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 
console=ttyS0,115200n8 debug print-fatal-signals=1 drm.debug=0x1e
PID hash table entries: 4096 (order: 1, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 6, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 5, 262144 bytes)
Memory: 749864K/1048576K available (5319K kernel code, 270K rwdata, 1048K 
rodata, 23040K init, 293K bss, 298712K reserved, 0K cma-reserved)
Preemptible hierarchical RCU implementation.
Tasks RCU enabled.
NR_IRQS: 512
MCIP: IDU supports 64 common irqs
clocksource: ARConnect GFRC: mask: 0x max_cycles: 
0x1cd42e4dffb, max_idle_ns: 881590591483 ns
Console: colour dummy device 80x25
Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
Idle Task [1] bf04da80
Trying to bring up CPU1 ...
archs-intc  : 2 priority levels (default 1) FIRQ (not used)

IDENTITY: ARCVER [0x52] ARCNUM [0x1] CHIPID [ 0x0]
processor [1]   : ARC HS38 R2.1 (ARCv2 ISA) 
Timers  : Timer0 Timer1 RTC [UP 64-bit] 
ISA Extn: atomic ll64 unalign (not used)
: mpy[opt 9] div_rem norm barrel-shift swap minmax swape
BPU : full match, cache:2048, Predict Table:16384
MMU [v4]: 

UDL's fbdev doesn't work for user-space apps

[Alexey Brodkin]

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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Alexey Brodkin]

Hi Jose,

On Mon, 2017-12-04 at 11:50 +, 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Alexey Brodkin]

Hi Jose,

On Mon, 2017-12-04 at 15:55 +, Jose Abreu wrote:
> On 04-12-2017 14:53, Alexey Brodkin wrote:
> > 
> > Full log you may find below.
> 
> Sorry but I meant /var/log/Xorg.0.log file.

Ooops... sorry... here is it.

-Alexey



# cat /var/log/Xorg.0.log 
[30.345] 
X.Org X Server 1.19.5
Release Date: 2017-10-12
[30.345] X Protocol Version 11, Revision 0
[30.345] Build Operating System: Linux 3.10.0-514.el7.x86_64 x86_64 
[30.346] Current Operating System: Linux axs103 
4.14.2-8-g95be6f762b7f-dirty #68 SMP PREEMPT Mon Dec 4 16:12:46 MSK 2017 arc
[30.346] Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 
console=ttyS0,115200n8 debug print-fatal-signals=1 drm.debug=0x1e
[30.346] Build Date: 01 December 2017  12:21:28PM
[30.346]  
[30.346] Current version of pixman: 0.34.0
[30.346]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[30.346] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[30.346] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan  1 00:00:30 
1970
[30.346] (==) Using config file: "/etc/X11/xorg.conf"
[30.346] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[30.347] (==) No Layout section.  Using the first Screen section.
[30.347] (==) No screen section available. Using defaults.
[30.347] (**) |-->Screen "Default Screen Section" (0)
[30.347] (**) |   |-->Monitor ""
[30.348] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[30.348] (**) |   |-->Device "Driver0"
[30.348] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[30.349] (==) Not automatically adding devices
[30.349] (==) Not automatically enabling devices
[30.349] (==) Not automatically adding GPU devices
[30.349] (==) Max clients allowed: 256, resource mask: 0x1f
[30.349] (WW) The directory "/usr/share/fonts/X11//TTF/" does not exist.
[30.349]Entry deleted from font path.
[30.349] (WW) The directory "/usr/share/fonts/X11//OTF/" does not exist.
[30.349]Entry deleted from font path.
[30.349] (WW) `fonts.dir' not found (or not valid) in 
"/usr/share/fonts/X11//100dpi/".
[30.349]Entry deleted from font path.
[30.349](Run 'mkfontdir' on "/usr/share/fonts/X11//100dpi/").
[30.349] (WW) `fonts.dir' not found (or not valid) in 
"/usr/share/fonts/X11//75dpi/".
[30.349]Entry deleted from font path.
[30.350](Run 'mkfontdir' on "/usr/share/fonts/X11//75dpi/").
[30.350] (==) FontPath set to:
/usr/share/fonts/X11//misc/,
/usr/share/fonts/X11//Type1/
[30.350] (==) ModulePath set to "/usr/lib/xorg/modules"
[30.350] (==) |-->Input Device ""
[30.350] (==) |-->Input Device ""
[30.350] (==) No Layout section. Using the default mouse configuration.
[30.350] (==) No Layout section. Using the default keyboard configuration.
[30.350] (II) Loader magic: 0x178528
[30.350] (II) Module ABI versions:
[30.350]X.Org ANSI C Emulation: 0.4
[30.350]X.Org Video Driver: 23.0
[30.350]X.Org XInput driver : 24.1
[30.350]X.Org Server Extension : 10.0
[30.350] (II) LoadModule: "armada"
[30.351] (II) Loading /usr/lib/xorg/modules/drivers/armada_drv.so
[30.352] (II) Module armada: vendor="X.Org Foundation"
[30.352]compiled for 1.19.5, module version = 0.0.0
[30.352]Module class: X.Org Video Driver
[30.352]ABI class: X.Org Video Driver, version 23.0
[30.352] (II) LoadModule: "mouse"
[30.352] (II) Loading /usr/lib/xorg/modules/input/mouse_drv.so
[30.353] (II) Module mouse: vendor="X.Org Foundation"
[30.353]compiled for 1.19.5, module version = 1.9.2
[30.353]Module class: X.Org XInput Driver
[30.353]ABI class: X.Org XInput driver, version 24.1
[30.353] (II) LoadModule: "kbd"
[30.353] (II) Loading /usr/lib/xorg/modules/input/kbd_drv.so
[30.353] (II) Module kbd: vendor="X.Org Foundation"
[30.353]compiled for 1.19.5, module version = 1.9.0
[30.354]Module class: X.Org XInput Driver
[30.354]ABI class: X.Org XInput driver, version 24.1
[30.354] (II) armada: Support for Marvell LCD Controller: 88AP510
[30.354] (II) armada: Support for Freescale IPU: i.MX6
[30.354] (II) armada: Support DisplayLink USB2.0: UDL
[30.354] (--) using VT number 2

[30.354] (WW) Falling back to old probe method for armada
[30.357] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[30.357] (II) armada(0): hardware: udl
[30.357] (II) armada(0): Creating default Display subsection in Screen 
section
"Default Screen Section" for depth/fbbpp 

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Emil Velikov]

On 4 December 2017 at 14:02, Jose Abreu  wrote:
> On 04-12-2017 13:16, Alexey Brodkin wrote:
>> Option  "kmsdev" "/dev/dri/card1"
>
> Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and
> if you don't specify the busID it will fallback for the first
> card that matches "armada-drm" or "imx-drm" or "udl".
>
As you've noticed, drmOpen can give you some 'nice' side-effects.
I'd recommend getting a list of devices with drmGetDevice{,s}2 and
applying $heuristics to filter the device you want.

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

On 04-12-2017 16:00, Alexey Brodkin wrote:
> [30.763] (II) armada(0): etnaviv: Xv: using YUY2 format intermediate YUV 
> target
>

I'm wondering if this means that target format for UDL is YUV ...

But anyway, I revisited your first email and noticed that you
said kmscube runs fine. Is this using etnaviv as renderer? And
you also said X is claiming the screen but nothing appears ...
which X client are you using to test this?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

On 04-12-2017 14:53, Alexey Brodkin wrote:
> Full log you may find below.

Sorry but I meant /var/log/Xorg.0.log file.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

On 04-12-2017 13:16, Alexey Brodkin wrote:
> Option  "kmsdev" "/dev/dri/card1"

Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and
if you don't specify the busID it will fallback for the first
card that matches "armada-drm" or "imx-drm" or "udl".

> 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.
>
>

Xorg.log can help confirm if everything is ok.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UDL's fbdev doesn't work for user-space apps

[Jose Abreu]

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).

e.g.:

Section "Device"
Identifier "Card0"
Driver "modesetting"
Option "kmsdev" "/dev/dri/card0"
Option "SWcursor" "true"
BusID "PCI:X:X:X"
EndSection

Best Regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel