Bug 57023 - The xf86-video-neomagic driver no longer works after the last update
The xf86-video-neomagic driver no longer works after the last update
Status: NEW
Product: xorg
Classification: Unclassified
Component: Driver/Neomagic
x86 (IA32) Linux (All)
: highest critical
Assigned To: Xorg Project Team
Xorg Project Team
Depends on:
  Show dependency treegraph
Reported: 2012-11-12 17:48 UTC by semeion7
Modified: 2013-08-16 19:49 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Sample patch to disable shadowFB (716 bytes, patch)
2012-12-28 05:26 UTC, Marc D. Williams
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description semeion7 2012-11-12 17:48:49 UTC
Description: The xf86-video-neomagic driver no longer works after the last update (version 1.2.7).

Crashes the pc, stands on a black screen.

The xf86-video-vesa is working fine!

Additional info:

* package version(s)
xf86-video-neomagic 1.2.7-3

* config and/or log files etc.
I'm using the same default configuration for over 1 year on my Thinkpad 600x. The problem only began this latest version of driver.

Steps to reproduce:
Crashes immediately after startx, xinit, etc.

Comment 1 semeion7 2012-11-14 08:58:25 UTC
obs: The 1.2.7 version is from Arch Linux official repository, same latest version from freedesktop.org.

Is bugged, no work!
Comment 2 Marc D. Williams 2012-11-29 21:33:46 UTC
On my particular system, Panasonic Toughbook CF-27, I found the problem to be
related to the loading of libshadow/shadowFB. Even though there is no XAA in
xorg 1.13 the neomagic source is still does a find for it and failing that it
falls back to shadowFB. This results in the black screen and inoperable keys.

The clue was in the log file:

=== Begin log ===
[   582.783] (II) Loading sub module "xaa"
[   582.784] (II) LoadModule: "xaa"
[   582.786] (WW) Warning, couldn't open module xaa
[   582.787] (II) UnloadModule: "xaa"
[   582.787] (II) Unloading xaa
[   582.787] (EE) NEOMAGIC: Failed to load module "xaa" (module does not
exist, 0)
[   582.787] (II) NEOMAGIC(0): Falling back to shadow
[   582.787] (II) Loading sub module "shadow"
[   582.787] (II) LoadModule: "shadow"
[   582.788] (II) Loading /usr/lib/xorg/modules/libshadow.so
[   582.789] (II) Module shadow: vendor="X.Org Foundation"
[   582.789]    compiled for 1.13.0, module version = 1.1.0
[   582.790]    ABI class: X.Org ANSI C Emulation, version 0.4
[   582.790] (**) NEOMAGIC(0): Using "Shadow Framebuffer" - acceleration
[   582.790] (--) NEOMAGIC(0): FB base address is set at 0xFD000000.
=== End log ===

So I pulled the Arch Linux source package for the neomagic driver and found
in line 1086 of neo_driver.c the section that looks for xaa and then calls
shadowFB. Commented out...

== Begin code ===
    if (!xf86LoadSubModule(pScrn, "xaa")) {
        xf86DrvMsg(pScrn->scrnIndex, X_INFO, "Falling back to shadow\n");
        nPtr->shadowFB = 1;
=== End code ===
...the neomagic driver worked fine. Also works if you just change
shadowFB = 1 to 0.

Using xorg.conf or something like xorg.conf.d/10-monitor.conf or what have you
with the option ShadowFB True/False/off/0 won't work as libshadow is already
loaded and is what is probably causing the problem. Not sure.
This is my workaround for the time being until a fix comes along.
Comment 3 Marc D. Williams 2012-12-28 05:26:51 UTC
Created attachment 72202 [details] [review]
Sample patch to disable shadowFB
Comment 4 Marc D. Williams 2012-12-28 05:34:16 UTC
Comment on attachment 72202 [details] [review]
Sample patch to disable shadowFB

Ach, my original comments didn't make it.
Loading shadow/shadowfb results in black screen and dead keyboard.
Changing shadow to shadowfb (in section: if (nPtr->shadowFB) results in
same problem.
Only solution was to disable shadowFB altogether. Works for me and at least
for one other reported on the Arch Linux forums.

Note, the patch line (1084) was against the Arch Linux neomagic package and
comes after another patch (git-fixes.patch).
So the actual line number may be around 1094 on vanilla source.

Comment 5 Chí-Thanh Christopher Nguyễn 2013-08-16 19:49:17 UTC
This is probably fixed in xf86-video-neomagic-1.2.8.