Bug 57023 - The xf86-video-neomagic driver no longer works after the last update
Summary: The xf86-video-neomagic driver no longer works after the last update
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Neomagic (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: highest critical
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL: https://bugs.archlinux.org/task/32604
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-12 17:48 UTC by semeion7
Modified: 2018-08-10 20:44 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


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

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.

https://bugs.archlinux.org/task/32604
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
disabled
[   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.

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

http://cgit.freedesktop.org/xorg/driver/xf86-video-neomagic/commit/?id=d7c14dfbac1b50ad484c0070075f060b53783550
Comment 6 GitLab Migration User 2018-08-10 20:44:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-neomagic/issues/2.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.