Bug 42734 - dosemu graphics broken in v3.3-rc1
Summary: dosemu graphics broken in v3.3-rc1
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jesse Barnes
URL:
Keywords:
Depends on:
Blocks: 42644
  Show dependency tree
 
Reported: 2012-02-05 19:10 UTC by Maciej Rutecki
Modified: 2012-03-03 09:59 UTC (History)
9 users (show)

See Also:
Kernel Version: 3.3-rc1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
kernel config (15.34 KB, application/octet-stream)
2012-02-06 20:37 UTC, Hans de Bruin
Details
lspci output (24.97 KB, text/plain)
2012-02-06 20:38 UTC, Hans de Bruin
Details
dmesg output (30.17 KB, text/plain)
2012-02-06 20:40 UTC, Hans de Bruin
Details

Description Maciej Rutecki 2012-02-05 19:10:24 UTC
Subject    : dosemu graphics broken in v3.3-rc1
Submitter  : Hans de Bruin <jmdebruin@xmsnet.nl>
Date       : 2012-02-02 22:25
Message-ID : 4F2B0D4D.3000304@xmsnet.nl
References : http://marc.info/?l=linux-kernel&m=132825899111982&w=2

This entry is being used for tracking a regression from 3.2. Please don't
close it until the problem is fixed in the mainline.
Comment 1 Hans de Bruin 2012-02-06 20:35:06 UTC
Bisect:

308e5bcbdb10452e8aba31aa21432fb67ee46d72 is the first bad commit
commit 308e5bcbdb10452e8aba31aa21432fb67ee46d72
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Mon Nov 14 14:51:28 2011 -0800

    drm: add an fb creation ioctl that takes a pixel format v5

    To properly support the various plane formats supported by different
    hardware, the kernel must know the pixel format of a framebuffer object.
    So add a new ioctl taking a format argument corresponding to a fourcc
    name from the new drm_fourcc.h header file.  Implement the fb creation
    hooks in terms of the new mode_fb_cmd2 using helpers where the old
    bpp/depth values are needed.

    v2: create DRM specific fourcc header file for sharing with libdrm etc
    v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
        update commit message
    v4: make fb_cmd2 handle field into an array for multi-object formats
        pull in Ville's fix for the memcpy in drm_plane_init
        apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
    v5: add 'flags' field for interlaced support (from Ville)

    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Reviewed-by: Rob Clark <rob.clark@linaro.org>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
Comment 2 Hans de Bruin 2012-02-06 20:37:06 UTC
Created attachment 72304 [details]
kernel config
Comment 3 Hans de Bruin 2012-02-06 20:38:37 UTC
Created attachment 72305 [details]
lspci output
Comment 4 Hans de Bruin 2012-02-06 20:40:04 UTC
Created attachment 72306 [details]
dmesg output
Comment 5 Florian Mickler 2012-02-11 15:47:10 UTC
First-Bad-Commit: 308e5bcbdb10452e8aba31aa21432fb67ee46d72
Comment 6 Chris Wilson 2012-02-11 20:05:54 UTC
Jesse, can you take a look? Seems like a weird failure just from adding an ioctl that wouldn't be used by dosemu.
Comment 7 Hans de Bruin 2012-02-12 21:36:14 UTC
It is a resolution problem. Switching to 640x480 is totally broken. In 3.2 it is partially broken, meaning kde makes mess of my screen, but good enough for dosemu. I think i need to take pictures and try some older kernels.

bash-4.1$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm
   1280x800       59.8*+
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
DVI1 disconnected (normal left inverted right x axis y axis)
TV1 disconnected (normal left inverted right x axis y axis)
bash-4.1$
Comment 8 Jesse Barnes 2012-02-13 16:15:09 UTC
Yeah seems a bit weird... maybe something broke in the fb compat somehow?  I'll look.
Comment 9 Jesse Barnes 2012-02-13 17:52:18 UTC
ah so this is xdosemu... yeah not sure why the addfb2 change would affect things.  Do kernels prior to 3.2 work better?  If so, maybe you can bisect the original failure to give us more clues.
Comment 10 Hans de Bruin 2012-02-19 13:10:29 UTC
When i use kde's tools to switch resolution things go bad with older kernels down to 2.6.35. I have not tested before that.

when i use xrandr to switch resolution 3.2.0 behaves normal with all the possible resolutions. So i think we can ignore kde's weirdness-es. 3.3-rc1 only breaks 640x480. I am able to switch back from 640x480 to other resolutions.

I have tried to capture what happens on a my mobile but that does not work. The changes on the screen happen to fast. Before the screen ends up black i see two or three flashes of windows moving downwards until the are out of range
Comment 11 Jesse Barnes 2012-02-23 16:31:33 UTC
Does this work in the drm-intel-fixes tree?  I just merged a patch there to fix load detection, but it seems like you might be hitting multiple bugs here...

git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel is the tree, drm-intel-fixes is the branch.
Comment 12 Rafael J. Wysocki 2012-02-23 22:33:57 UTC
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Comment 13 Hans de Bruin 2012-02-26 12:53:35 UTC
The drm-intel-fixes work. Unfortunately, when i switched back to the current tree (..b52b800) the problem was gone too. Do we leave it at this or sould i try to bisect the 'fix'?
Comment 14 Hans de Bruin 2012-02-26 13:10:24 UTC
A little bit to fast. In the current tree switching to 640x480 works with xrandr. switching with kde and xdosemu does not. Switching to 640x480 with xrandr and then switching to fullscreen mode in dosemu does not work either.
Comment 15 Hans de Bruin 2012-02-28 20:53:34 UTC
There is something else that is bothering me. During the login process into kde, while showing the kde splash screen and later when programs start filling the system tray, black boxes flash in the top left corner of the screen. They are about the size of the xdosemu dosbox or graphics screen. They are not totally black, There seems to be data in the first lines. It happens very fast.
Comment 16 Hans de Bruin 2012-03-03 09:13:04 UTC
Jesse,

The patches are in mainline and my resolution problems and black box flashes are gone.

Maciej 

I think we can close this call.
Comment 17 Maciej Rutecki 2012-03-03 09:59:00 UTC
Thanks for the update. Closing

Note You need to log in before you can comment on or make changes to this bug.