Bug#594093: marked as done (mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)?)
Your message dated Wed, 17 Aug 2011 17:33:41 + with message-id and subject line Bug#594093: fixed in mplayer 2:1.0~rc4.dfsg1+svn33713-1 has caused the Debian Bug report #594093, regarding mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 594093: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594093 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: mplayer Version: 2:1.0~rc3+svn20100502-3 Severity: normal Steps to reproduce: 1) wget http://ftp.acc.umu.se/pub/debian-meetings/2009/debconf9/low/1050_Lightning_talk_Redirecting_require.ogv 2) mplayer -vo sdl 1050_Lightning_talk_Redirecting_require.ogv 3) look at the text around 00:16 4) mplayer -vo x11 1050_Lightning_talk_Redirecting_require.ogv 5) look at the text around 00:16 Expected results: 3 & 5) text is clearly readable Actual results: 3) text is clearly readable http://lindi.iki.fi/lindi/mplayer/mplayer.sdl.png 5) text looks garbled. Is this wrong byteorder? http://lindi.iki.fi/lindi/mplayer/mplayer.x11.png More info: 1) This is on armel (openmoko freerunner) with xserver-xorg 1:7.5+6 xserver-xorg-video-fbdev 1:0.4.2-2 2) I also see the problem with "-vo fbdev" which should bypass X. This is why I am reporting it against mplayer and not X. 3) xdpyinfo reports under name of display::0.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:10707000 X.Org version: 1.7.7 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x400012, revert to None number of extensions:24 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:480x640 pixels (203x201 millimeters) resolution:60x81 dots per inch depths (7):16, 1, 4, 8, 15, 24, 32 root window id:0x43 depth of root window:16 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:64 preallocated pixels:black 0, white 65535 options:backing-store NO, save-unders NO largest cursor:480x640 current input event mask:0xfa200c ButtonPressMask ButtonReleaseMaskButtonMotionMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:2 default visual id: 0x21 visual: visual id:0x21 class:TrueColor depth:16 planes available colormap entries:64 per subfield red, green, blue masks:0xf800, 0x7e0, 0x1f significant bits in color specification:8 bits visual: visual id:0x41 class:TrueColor depth:32 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits 4) This looks somewhat similar to mupdf bug: http://bugs.ghostscript.com/show_bug.cgi?id=690932 5) I also see this with the Xorg driver optimized for this hardware: xserver-xorg-video-glamo 0.0.0+20091108.git9918e082-1 6) With xserver-xorg-video-glamo the xdpyinfo output is slightly different: --- xdpyinfo.fbdev 2010-08-23 18:36:02.0 +0300 +++ xdpyinfo.glamo 2010-08-23 18:35:42.0 +0300 @@ -17,7 +17,7 @@ depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 -focus: window 0x400012, revert to None +focus: window 0x62, revert to None number of extensions:24 BIG-REQUESTS Composite @@ -47,1
Bug#594093: marked as done (mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)?)
Your message dated Wed, 25 Aug 2010 17:05:17 +0200 with message-id <87pqx6ravm@faui44a.informatik.uni-erlangen.de> and subject line Re: Bug#594093: mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? has caused the Debian Bug report #594093, regarding mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 594093: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594093 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: mplayer Version: 2:1.0~rc3+svn20100502-3 Severity: normal Steps to reproduce: 1) wget http://ftp.acc.umu.se/pub/debian-meetings/2009/debconf9/low/1050_Lightning_talk_Redirecting_require.ogv 2) mplayer -vo sdl 1050_Lightning_talk_Redirecting_require.ogv 3) look at the text around 00:16 4) mplayer -vo x11 1050_Lightning_talk_Redirecting_require.ogv 5) look at the text around 00:16 Expected results: 3 & 5) text is clearly readable Actual results: 3) text is clearly readable http://lindi.iki.fi/lindi/mplayer/mplayer.sdl.png 5) text looks garbled. Is this wrong byteorder? http://lindi.iki.fi/lindi/mplayer/mplayer.x11.png More info: 1) This is on armel (openmoko freerunner) with xserver-xorg 1:7.5+6 xserver-xorg-video-fbdev 1:0.4.2-2 2) I also see the problem with "-vo fbdev" which should bypass X. This is why I am reporting it against mplayer and not X. 3) xdpyinfo reports under name of display::0.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:10707000 X.Org version: 1.7.7 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x400012, revert to None number of extensions:24 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:480x640 pixels (203x201 millimeters) resolution:60x81 dots per inch depths (7):16, 1, 4, 8, 15, 24, 32 root window id:0x43 depth of root window:16 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:64 preallocated pixels:black 0, white 65535 options:backing-store NO, save-unders NO largest cursor:480x640 current input event mask:0xfa200c ButtonPressMask ButtonReleaseMaskButtonMotionMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:2 default visual id: 0x21 visual: visual id:0x21 class:TrueColor depth:16 planes available colormap entries:64 per subfield red, green, blue masks:0xf800, 0x7e0, 0x1f significant bits in color specification:8 bits visual: visual id:0x41 class:TrueColor depth:32 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits 4) This looks somewhat similar to mupdf bug: http://bugs.ghostscript.com/show_bug.cgi?id=690932 5) I also see this with the Xorg driver optimized for this hardware: xserver-xorg-video-glamo 0.0.0+20091108.git9918e082-1 6) With xserver-xorg-video-glamo the xdpyinfo output is slightly different: --- xdpyinfo.fbdev 2010-08-23 18:36:02.0 +0300 +++ xdpyinfo.glamo 2010-08-23 18:35:42.0 +0300 @@ -17,7 +17,7 @@ depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 -focus: window 0x400012, revert to None +focus: window 0x62,
