Hi Mark,

I believe the general tendency is to move away from FB towards KMS for 
everything. 

You could try and see if setting CONFIG_FB_UDL=m fixes it, although I am
not sure what the story with the FB_CONFIGs is.

The following are the active ones:
$ grep CONFIG_FB config-generic |grep -v "is not set"
CONFIG_FB=y
CONFIG_FB_I810=m
CONFIG_FB_I810_GTF=y
CONFIG_FB_I810_I2C=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_VESA=y
CONFIG_FB_VGA16=m
CONFIG_FB_VIRTUAL=m
CONFIG_FB_EFI=y
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA_BACKLIGHT=y
CONFIG_FB_RADEON_BACKLIGHT=y
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY_BACKLIGHT=y

vs the non active ones:
generic |grep "is not set" |wc -l
64

regards,
Michele

Hi Michele,

I'm aware that there is a general move to KMS, I only mentioned that the former udlfb module worked to help identify what udlfb might have been doing that the KMS udl module doesn't.

I'll find some time to build a custom kernel with the udlfb module enabled, to verify that it was the change to KMS udl that stopped my screen from working - it hasn't worked for quite a while, and I only got around to reporting the issue over the holiday break.

Thanks,
Mark.

Hi Mark,

likely the new UDL is buggy with Framebuffer. Does it
work with xorg? (https://wiki.archlinux.org/index.php/DisplayLink)

This would tell us if it is a specific issue when used directly as framebuffer
or if it is a general brokenness

regards,
Michele

So I borrowed one of these out of curiosity. Indeed this seems to be a fallout
of the udl kms driver.

At least on 3.13-rc7 with udlfb compiled as a module,
mplayer -vo fbdev:/dev/fb1 -vf scale=800:480 foo.mp4

works correctly. The udl driver instead seems to just not turn on the display.

Trying to use the udl kms driver within xorg leaves the screen black as well.
And has the following in the logs:
[  1257.825] (--) FBDEV(0): Virtual size is 800x480 (pitch 800)      
[  1257.825] (**) FBDEV(0):  Built-in mode "current"                 
[  1257.825] (==) FBDEV(0): DPI set to (96, 96)                      
[  1257.825] (II) Loading sub module "fb"                            
[  1257.825] (II) LoadModule: "fb"                                   
[  1257.825] (II) Loading /usr/lib64/xorg/modules/libfb.so           
[  1257.825] (II) Module fb: vendor="X.Org Foundation"               
[  1257.825]    compiled for 1.14.4, module version = 1.0.0          
[  1257.825]    ABI class: X.Org ANSI C Emulation, version 0.4       
[  1257.825] (**) FBDEV(0): using shadow framebuffer                 
[  1257.825] (II) Loading sub module "shadow"                        
[  1257.825] (II) LoadModule: "shadow"                               
[  1257.825] (II) Loading /usr/lib64/xorg/modules/libshadow.so       
[  1257.825] (II) Module shadow: vendor="X.Org Foundation"           
[  1257.825]    compiled for 1.14.4, module version = 1.1.0          
[  1257.825]    ABI class: X.Org ANSI C Emulation, version 0.4       
[  1257.826] (==) FBDEV(0): Backing store disabled                   
[  1257.826] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument            
[  1257.826] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument            
[  1257.826] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument            
...snip...
[  1257.827] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument      
[  1257.827] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument      
[  1257.827] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument      
[  1257.827] (==) FBDEV(0): DPMS enabled                       
[  1257.827] (==) RandR enabled                                
[  1257.833] (II) SELinux: Disabled by boolean                 
[  1257.834] (II) AIGLX: Screen 0 is not DRI2 capable

Hi,

I've been meaning to ask, since Michele has shown that the 'udl' module isn't working, and the 'udlfb' still is, is there anything further I need to do to assist with troubleshooting/resolving this issue?

Thanks,
Mark.

I'm guessing this is more of an mplayer on the kms driver not being supported

it might be worth trying udl.fb_defio=1 on the command line.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.13.5-100.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Hello,

I'd like to report this is still an issue. Doing udl.fb_defio does not fix the issue. I can confirm that this works on RHEL6 (Fedora 14?) with the udlfb kernel module.

The MIMO screens turn green when they are activated successfully, that never happens with udl kernel driver.

I've noticed upon plugging this device in, my background in Gnome 3, the top left 800x480 pixels (the exact size of this MIMO device) is my entire background, so it's like there's a small overlay of my background on top of my background. Strange.

Doing a dd of /dev/urandom into the newly-created /dev/fb1, which used to draw all sorts of colorful pixels (and still does using RHEL6+udlfb), now does absolutely nothing.

[174163.499691] usb 3-1: new high-speed USB device number 2 using xhci_hcd
[174163.511537] usb 3-1: device descriptor read/8, error -32
[174163.623652] usb 3-1: device descriptor read/8, error -32
[174163.876935] usb 3-1: new high-speed USB device number 3 using xhci_hcd
[174163.892044] usb 3-1: New USB device found, idVendor=17e9, idProduct=016b
[174163.892051] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[174163.892055] usb 3-1: Product: MIMO
[174163.892058] usb 3-1: Manufacturer: DisplayLink
[174163.892061] usb 3-1: SerialNumber: 1253002399
[174163.958629] [drm] vendor descriptor length:17 data:17 5f 01 00 15 05 00 01 03 00 04
[174164.033928] udl 3-1:1.0: fb1: udldrmfb frame buffer device
[174164.033938] [drm] Initialized udl 0.0.1 20120220 on minor 1
[174164.034015] usbcore: registered new interface driver udl
[174164.195210] [drm] write mode info 153

Linux localhost.localdomain 3.11.10-100.fc18.x86_64 #1 SMP Mon Dec 2 20:28:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

More details:

My typical mode of operation is to display just a photo on this device. I use it as a status sign outside of my office to report my location on-campus. I have code here that used to work to display images:

http://allmybase.com/framebugger/

Or, as a bash equivalent:

#!/bin/sh

FILE=/var/www/html/brose/assets/current.jpg
TEMP=`mktemp -u /tmp/XXXXXXXX`
TEMP=${TEMP}.png

TEMP2=`mktemp /tmp/XXXXXXXX`

while [ 1 ]
do
	convert -resize '800x480!' $FILE $TEMP
	mkdfiff -f RGB16 $TEMP >$TEMP2 
	dd if=$TEMP2 of=/dev/fb1 bs=1 skip=24 
	sleep 5
done

Again, this works just fine with RHEL6+udlfb, but fails with the newer udl driver. I have been attempting to compile a kmod-udlfb for Fedora, but I have been met with limited success. Any assistance would be appreciated, and I would be happy to test whatever code/options and report back to gather additional information.

Hi, more information:

I get the same exact results on fully-updated Fedora 19 and Fedora 20 machines. X does indeed work when I set it up through the gnome GUI, but that is not my desired mode of operation. I want to be able to dd pictures directly into the framebuffer to use this device as a status sign. Again, udlfb worked perfectly for this, udl is broken. Please advise how I can troubleshoot or provide additional details.

Thanks.

Created attachment 879702 [details]
udlfb for newer kernels

Failing any immediate solution for this issue, I have recompiled the udlfb kernel module for modern kernels, using the latest kernel source from kernel.org. I have attached the SRPM to this ticket. You will need to make a couple of changes to get this to work on your local installation:

1) Change the kernel version in the top of the spec file based on the output of "uname -a"

2) Add "exclude=kernel-debug-devel" to /etc/mock/default.cfg under the [main] section. You want to build this against the mainline kernel, not the debug kernel.

3) Blacklist the udl module and force the loading of udlfb in /etc/modprobe.d

I am still happy to help track down the issue with the udl driver. Please let me know what I can do to assist. Now that I have the udlfb driver on Fedora 18/19/20, running commands directly against the framebuffer device works perfectly again!

when you plug this device in, it should hotplug into your X session,

so you should see it in /var/log/Xorg.0.log appearing and in xrandr

maybe see if xrandr can move it around,

to avoid it being hotplugged you need an xorg.conf with Option "AutoAddGPU" "FALSE"

Now after that in theory it should work as a framebuffer device, but the framebuffer emulation is very limited on these devices, and defio isn't working that great with the kms driver.

So I planned to take a look again at this and re-borrowed a Mimo display. With 3.14.2 it all works out of the box. I.e. just plugged it, xrandr recognized it and I was able to set it up via the gnome desktop applet. I guess we can close this?

Hi, 

Not quite, the issue isn't whether or not X will work on the device, it's whether or not the device will operate as a framebuffer properly. Try to output a picture to it like I am doing above (convert, mkdfiff, dd), or try to play a movie on it with mplayer as a framebuffer device as O.P. was talking about. You will see it does not work as expected with the new driver as it does with the old.

Thanks for taking a look!

Well X surely did not work last time I tested it and now it does.
I am not really interested in the framebuffer usecase, so I won't dig much 
further here. The interested ones can always recompile their own kernels for that
or fix the real issue in udl as mentioned by Dave in c#12.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.14.4-100.fc19.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.

If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.