Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#52704 - [xf86-video-fbdev] 0.4.4-6 git-fixes.patch - patch #3 breaks X in vbox

Attached to Project: Arch Linux
Opened by Jeff Hodd (jghodd) - Wednesday, 25 January 2017, 04:38 GMT
Last edited by Andreas Radke (AndyRTR) - Friday, 27 January 2017, 09:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Laurent Carlier (lordheavy)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Description: Patch #3 from git-fixes.patch breaks X when used in virtualbox


Additional info:
* 0.4.4-6
* attached:
- the broken Xorg.0.log file

Steps to reproduce:

When using a clean X installation without an xorg.conf file, X fails to start when running in a virtualbox environment. A build using only patches 1 & 2 from git-fixes.patch restores normal software behaviour. I attempted to narrow the issue down to a single location in the patch code, but all parts of patch 3 cause the failure. Patches 1 & 2 appear to work as intended. Patch 4 is a modification of patch 3 and is irrelevant.
This task depends upon

Comment by Jeff Hodd (jghodd) - Thursday, 26 January 2017, 20:58 GMT
Attached is the Xorg.0.log file from a successful boot. Note that the difference is what happens after unloading the fbdevhw submodule. In the broken log (patched xf86-video-fbdev), x startup dies right there. In the working log (xf86-video-fbdev patches 3 & 4 removed), x startup goes on to load both the vbe and int10 submodules, and then successfully initialises vesa. Patch 3 seems to short-circuit the loading of vbe and int10 (and the subsequent vesa initialisation).
Comment by Jeff Hodd (jghodd) - Thursday, 26 January 2017, 22:41 GMT
Let me know if you need any other logs.

As far as I can tell, patch 3 breaks vesafb. I've tried a number of workarounds, none successfully. So far, the only thing that works is building out the package without patches 3 & 4.

What bothers me is that the archiso live media boots up and starts X successfully. The installation, extracted from the same live media, doesn;t work. Since the installation is just an unsquashed replica of the live media's root partition, it's practically identical, but only works with the modified version of xf86-video-fbdev. The only differences are the initramfs hooks (no archiso hooks - and yes, I've tried adding the kms hook) and the installation uses grub vs syslinux for its bootloader. I've burrowed down into both trying to figure out if there's some other difference, but I can;t find anything else. I think you'd agree, that if there is something in the system setup that can be done to satisfy patch 3, that would be preferable to modifying the patch. Any ideas?
Comment by Jeff Hodd (jghodd) - Friday, 27 January 2017, 18:44 GMT
Ok. I did some manual code tracing and I believe what's happened is that patches 3/4 break the fbdev failsafe - and I think it's fixable.

First, I want to let you know that including virtualbox-guest-modules-arch does 'fix' the problem - X starts up successfully with vboxvideo. This is not an unacceptable solution for me - I'll just include the modules with every build going forward. However, the fbdev failsafe was coded for a reason and it does work when needed and when used properly as a failsafe.

Both FBDevPciProbe and FBDevPreInit ultimately call either fbdev_pci_open or fbdev_open, depending on the value of the pci_device pointer. If the pointer is null, fbdev_open is called; if the pointer is not null, fbdev_pci_open is called. If the pci data is garbage and fbdev_pci_open is called, the operation fails, and I believe that's what's happening when running the OS in vbox without the vboxvideo driver. The failsafe occurs when you pass NULL to either FBDevPciProbe or FBDevPreInit. A NULL pci_device pointer parameter will cause both of these functions to call fbdev_open instead of fbdev_pci_open, and that's the key to the failsafe. If fbdev_open first tries to acquire the name of the framebuffer device via the environment (dev = getenv("FRAMEBUFFER")) and if it's unable to get the device name, it makes a last ditch effort using /dev/fb0. I believe that's how it worked when fbdev was unable to acquire valid pci data for the system graphics device (vbox without vboxvideo).

I think this can be fixed as follows:

FBDevPciProbe:

if (fbdevHWProbe(dev, device, NULL)) {
pScrn->driverVersion = FBDEV_VERSION;
pScrn->driverName = FBDEV_DRIVER_NAME;
pScrn->name = FBDEV_NAME;
pScrn->Probe = FBDevProbe;
pScrn->PreInit = FBDevPreInit;
pScrn->ScreenInit = FBDevScreenInit;
pScrn->SwitchMode = fbdevSwitchMode;
pScrn->AdjustFrame = fbdevAdjustFrame;
pScrn->EnterVT = fbdevEnterVT;
pScrn->LeaveVT = fbdevLeaveVT;
pScrn->ValidMode = fbdevValidMode;

xf86DrvMsg(pScrn->scrnIndex, X_CONFIG,
"claimed PCI slot %d@%d:%d:%d\n",
dev->bus, dev->domain, dev->dev, dev->func);
xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"using %s\n", device ? device : "default device");
}
else if (fbdevHWProbe(NULL, device, NULL)) {
pScrn->driverVersion = FBDEV_VERSION;
pScrn->driverName = FBDEV_DRIVER_NAME;
pScrn->name = FBDEV_NAME;
pScrn->Probe = FBDevProbe;
pScrn->PreInit = FBDevPreInit;
pScrn->ScreenInit = FBDevScreenInit;
pScrn->SwitchMode = fbdevSwitchMode;
pScrn->AdjustFrame = fbdevAdjustFrame;
pScrn->EnterVT = fbdevEnterVT;
pScrn->LeaveVT = fbdevLeaveVT;
pScrn->ValidMode = fbdevValidMode;

xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"using %s\n", device ? device : "default device");

}
else {
pScrn = NULL;
}

FBDevPreInit:

if (!fbdevHWInit(pScrn, pci_dev, xf86FindOptionValue(fPtr->pEnt->device->options, "fbdev")))
if (!fbdevHWInit(pScrn, NULL, xf86FindOptionValue(fPtr->pEnt->device->options, "fbdev")))
return FALSE;


I can test this solution and let you know if it works as expected, but this would restore the fbdev failsafe.
Comment by Jeff Hodd (jghodd) - Friday, 27 January 2017, 19:34 GMT
The above solution does indeed work as expected. It restores the failsafe.

fbdev.c is attached. If you decide to use it, please let me know.

Meanwhile, I'll include virtualbox-guest-modules-arch in my builds.
   fbdev.c (32.6 KiB)
Comment by Andreas Radke (AndyRTR) - Sunday, 05 February 2017, 10:25 GMT
You should report this upstream to confirm this is a proper fix.

You might also want to apply at least one more commit that seems important:
https://cgit.freedesktop.org/xorg/driver/xf86-video-fbdev/commit/?id=2c5eba85740e6a7ced8ada0ee45fdd74e4bca364
Comment by Jan de Groot (JGC) - Sunday, 12 November 2017, 22:41 GMT
Please test xf86-video-fbdev-0.4.4+12+ge0bce0d-1, this version is 10 commits newer than the current version in repository. If this doesn't fix your problem, please file a bug upstream instead.

Loading...