EMGD 1.5.2 on Linux: not working SDVO output

[TVane]

We use EMGD driver for embedded board Kontron KTUS15. The board chipset is US15W and there is a SDVO / DVI-D video converter Silicon Image 1364. Previous version of EMGD worked correctly with this configuration. After upgrade to Xorg 1.9 and EMGD 1.5.2 xserver fails with strange error - see part of Xorg.0.log below. Any help how to prevent the regression? Thanks

...

[ 2980.322] (II) LoadModule: "emgd"

[ 2980.323] (II) Loading /usr/lib/xorg/modules/drivers/emgd_drv.so[ 2980.324] (II) Module emgd: vendor="Intel(R) Corporation"[ 2980.324] compiled for 1.9.0, module version = 1.5.1816[ 2980.324] Module class: X.Org Video Driver[ 2980.324] ABI class: X.Org Video Driver, version 8.0[ 2980.324] (II) EMGD: Intel(R) Embedded Media and Graphics Driver version 1.5.1816 for: Intel US15W Class[ 2980.324] (++) using VT number 6 [ 2980.329] (II) EMGD(0): Creating default Display subsection in Screen section "Default Screen" for depth/fbbpp 24/32[ 2980.329] (==) EMGD(0): RGB weight 888[ 2980.329] (==) EMGD(0): Default visual is TrueColor[ 2980.329] drmOpenDevice: node name is /dev/dri/card0[ 2980.330] drmOpenDevice: open result is 8, (OK)[ 2980.330] drmOpenByBusid: Searching for BusID PCI:00:00:00[ 2980.330] drmOpenDevice: node name is /dev/dri/card0[ 2980.330] drmOpenDevice: open result is 8, (OK)[ 2980.330] drmOpenByBusid: drmOpenMinor returns 8[ 2980.330] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0[ 2980.331] drmOpenDevice: node name is /dev/dri/card1

...

[ 2980.406] drmOpenByBusid: drmOpenMinor returns -1

[ 2980.406] drmOpenDevice: node name is /dev/dri/card0[ 2980.406] drmOpenDevice: open result is 8, (OK)[ 2980.406] drmOpenDevice: node name is /dev/dri/card0[ 2980.406] drmOpenDevice: open result is 8, (OK)[ 2980.407] drmGetBusid returned ''[ 2980.407] (II) EMGD(0): Chipset: "Intel SCH US15 Chipset"[ 2980.407] (II) EMGD(0): Checking for new style options[ 2980.407] (II) EMGD(0): Processing version 7.0 options[ 2980.407] (II) EMGD(0): Using configuration 1[ 2980.407] (II) EMGD(0): Checking for US15 specific configuration.[ 2980.407] (II) EMGD(0): Checking for non-chipset specific configuration.[ 2980.407] (II) EMGD(0): Option processing done![ 2980.580] (II) EMGD(0): Valid Display Configurations:[ 2980.580] (II) EMGD(0): DC: 0x00000041[ 2980.580] (II) EMGD(0): DC: 0x00200042[ 2980.580] (II) EMGD(0): DC: 0x00200048[ 2980.580] (II) EMGD(0): DC: 0x00000021[ 2980.580] (II) EMGD(0): DC: 0x00000000[ 2980.582] (II) EMGD(0): Using Display Configuration 0x00000041[ 2980.582] (II) EMGD(0): Given depth (24) is not supported.[ 2980.582] (II) UnloadModule: "emgd"[ 2980.582] (EE) Screen(s) found, but none have a usable configuration.[ 2980.582]Fatal server error:[ 2980.583] no screens found

[Kirk_B_Intel]

That is an odd one. It appears that something is telling us that 24 bits per pixel is NOT supported by the hardware (odd for a DVI) but that would be either the SI1364 telling us that, OR the EDID on the display (you do have edid turned on in your config, right?).

You could try setting your Screen section to allow 18bpp and see if that changed anything.

Hope this helps.

[TVane]

Thanks Kirk for the fast reply. The error message in Xorg.log was misleading, the problem is not related to bit depth at all – xserver failed with same error for 8, 16 and 18 bpp too.

Finally I found that emgd.ko module has not get upgraded and the old version was used. As soon I corrected this, xserver works with 24bpp.

Something like version check between kernel module and driver would have helped finding what was wrong. I also do not understand why the kernel module for latest and older emgd has the same version number 1.5.15.3082 although they are not compatible.

[Kirk_B_Intel]

I am very glad you discoverd that module mismatch as that is something I would not have thought of right away. I am concerned that such a mismatch is even possible and would result in such as odd error. I will ask our Linux developers to look into that situation and see if we can come up with a more "elegant" failure mode for such an occurance.