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.
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>
Created attachment 72304 [details] kernel config
Created attachment 72305 [details] lspci output
Created attachment 72306 [details] dmesg output
First-Bad-Commit: 308e5bcbdb10452e8aba31aa21432fb67ee46d72
Jesse, can you take a look? Seems like a weird failure just from adding an ioctl that wouldn't be used by dosemu.
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$
Yeah seems a bit weird... maybe something broke in the fb compat somehow? I'll look.
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.
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
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.
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
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'?
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.
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.
Jesse, The patches are in mainline and my resolution problems and black box flashes are gone. Maciej I think we can close this call.
Thanks for the update. Closing