Bug#970574: xserver-xorg-video-amdgpu: ABI changed (24.0 to 24.1) but not the dependencies
Hi, deb...@iremonger.me.uk (2021-06-19 at 1704.32 +0100): > In short, I think this bug report should now be closed unless there > is an apparent issue specifically in buster or bullseye now [??] ? Currently I have xserver-xorg-video-amdgpu 19.1.0-2 with xserver-xorg-core 2:1.20.11-1 and it keeps working (updating Sid every now and then). The issue existed for a brief time, but probably does not matter in releases if they have debs in sync. Even if they do not explicitly request a given version, the avaliable versions implicitly avoid the problem (sorry, no machines to test them, but by numbers, Buster has an older video-amdgpu package, 18.1.99+git20190207-1, and Bullseye is like Sid now). Thus I agree it can be closed. For the record, in the rare case someone hits the issue, old log also had: ---8<--- [ 144.270] (II) Module ABI versions: [ 144.270]X.Org ANSI C Emulation: 0.4 [ 144.270]X.Org Video Driver: 24.0 [ 144.270]X.Org XInput driver : 24.1 [ 144.270]X.Org Server Extension : 10.0 --->8--- Notice the 24.0. Last ones have lines like: ---8<--- [24.338] (II) Module ABI versions: [24.338]X.Org ANSI C Emulation: 0.4 [24.339]X.Org Video Driver: 24.1 [24.339]X.Org XInput driver : 24.1 [24.339]X.Org Server Extension : 10.0 ... [24.374] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so [24.380] (II) Module amdgpu: vendor="X.Org Foundation" [24.380]compiled for 1.20.9, module version = 19.1.0 [24.380]Module class: X.Org Video Driver [24.380]ABI class: X.Org Video Driver, version 24.1 --->8--- Notice the two 24.1 for video drivers. xserver-xorg-video-amdgpu's "Depends" line still lists xorg-video-abi-24, without .1. Cheers, GSR
Bug#970574: xserver-xorg-video-amdgpu: ABI changed (24.0 to 24.1) but not the dependencies
Package: xserver-xorg-video-amdgpu Version: 19.1.0-2 Severity: important Dear Maintainer, After updating xserver-xorg-video-amdgpu from 19.1.0-1 to 19.1.0-2, startx stopped working. It seems to be a mismatch of ABI versions and .deb metadata (provides, breaks, conflicts, etc). The log had: ---8<--- [ 144.299] (II) LoadModule: "amdgpu" [ 144.299] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so [ 144.305] (II) Module amdgpu: vendor="X.Org Foundation" [ 144.305]compiled for 1.20.9, module version = 19.1.0 [ 144.305]Module class: X.Org Video Driver [ 144.305]ABI class: X.Org Video Driver, version 24.1 [ 144.306] (EE) amdgpu: module ABI minor version (1) is newer than the server's version (0) [ 144.306] (EE) Failed to load module "amdgpu" (module requirement mismatch, 0) [ 144.306] (II) LoadModule: "wacom" [ 144.306] (II) Loading /usr/lib/xorg/modules/input/wacom_drv.so [ 144.307] (II) Module wacom: vendor="X.Org Foundation" [ 144.307]compiled for 1.20.4, module version = 0.34.99 [ 144.307]Module class: X.Org XInput Driver [ 144.307]ABI class: X.Org XInput driver, version 24.1 ... [ 144.309] (EE) No drivers available. [ 144.309] (EE) Fatal server error: [ 144.309] (EE) no screens found(EE) [ 144.309] (EE) --->8--- The solution was updating xserver-xorg-core by hand, from 2:1.20.3-1 to 2:1.20.9-1. ABI 24.0 does not seem to be good enough for video drivers and debs like xserver-xorg-video-amdgpu should request a newer xserver-xorg-core, or drivers should stay compatible with core (wacom reports 24.1, and it was working days ago with that, so for xinput drivers it did not matter). Cheers, GSR
Bug#914267: mesa: [regression] with Mesa 18.2.5-2 the charackter model in Tomb Raider is no longer rendered.
Package: mesa Version: 18.2.5-2 Followup-For: Bug #914267 That looks like missing shaders. I hit a similar thing with mpv (just blue window, sound but no video) after upgrading 18.2.5-1 => 18.2.5-2, luckly showing some output that later helped with searches. ---8<--- [vo/gpu/opengl] fragment shader compile log (status=0): [vo/gpu/opengl] 0:36(27): error: invalid input layout qualifier used [vo/gpu/opengl] [vo/gpu/opengl] shader link log (status=0): error: linking with uncompiled/unspecialized shader --->8--- Bug 914303 could be the same too, garbled or single color output could mean shaders not working because they failed to compile. Looking up the error text, I found the culprit could be gcc, creating faulty mesa binaries. https://bugs.freedesktop.org/show_bug.cgi?id=108646 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 Cheers, GSR
Bug#613137: xserver-xorg-video-radeon: no video signal or kbd after manually launching X
Hi, jcris...@debian.org (2011-02-13 at 1104.39 +0100): back, the screen shows the bg (or maybe it was left from previous run) and then monitor goes into sleep immediately, ignoring kbd as original report. You should probably trim your xorg.conf down to just monitor sections to stop other stuff interfering... Spliting it into files inside xorg.conf.d/ and playing renaming game (easier to move foo.conf to foo.conf- to see what part is wrong) I found the problem of the black screen, but also issues with how things are done with outputs and config. Maybe worth new bugs? The problem line was 'FontPath unix/:7100' XFS is running, but seems that having that line in the conf makes it go nuts in unrelated ways. The left issues are: System sees an inexistant monitor on VGA connector. The cable is there, but the monitor is off and not responding (otherwise it would had seen valid vendor name, etc via DDC, right?). Even so, the system insists in giving it some random settings and keep the output fully enabled. Once that monitor is configured via .conf file(s) with better Modelines than DDC ever provided, it keeps the output enabled even when the config has 'Option Enable false'. At least xrandr keeps the modelines right. Set DVI-0 to be primary wihth 'Option Primary true', but that one is ignored and VGA is still enabled. It is trully obsessed with having that output even if not needed and told to forget about it for now. ;] Workaround is to issue xrandr --output VGA-0 --off in ~/.xsession, so apps do not get confused with false overlapping monitors (maximize, etc). I guess this bug can be closed. Thanks for the help. GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110214210907.GA10450@crossbow.battleship
Bug#607510: Suggestion about slow radeon, debian bug 607510
Hi, daen...@debian.org (2011-02-11 at 1035.03 +0100): On Fre, 2011-02-11 at 05:54 +0100, GSR wrote: Could you check MigrationHeuristic setting? And try with greedy? This option doesn't have any effect with current upstream xserver and KMS, and even with older xservers where it accidentally had an effect, it's probably better to use the radeon driver option EXAPixmaps off if you want to prevent acceleration on all pixmaps other than the visible screen. Might be worth trying the current X server and driver in sid first though to see if they're doing better. With KMS 6.13.1-2+squeeze1 (Sid has 6.13.2-2, update scheduled in some days) removing MigrationHeuristic from xorg.conf gives acceptable speed, same than with it. So at some point in the past, the issue that required greedy was solved. The obvious test was 5 sec canvas refreshes in GIMP when repositioning the content. Thanks for the tip. GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211192658.GA6230@crossbow.battleship
Bug#607510: Suggestion about slow radeon, debian bug 607510
Hi: Could you check MigrationHeuristic setting? And try with greedy? ---8--- Section Device ... Driver radeon ... # Option MigrationHeuristic smart # Near as slow as with default/always http://nouveau.freedesktop.org/wiki/EXA Option MigrationHeuristic greedy # Fast as XAA, X.Org X Server 1.6.5, 2009-10-29 http://lists.freedesktop.org/archives/xorg/2008-May/thread.html#35451 ... EndSection ---8--- GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110211045432.GA31172@crossbow.battleship
Bug#546588: Suggestion for slow radeon (debian bug 546588)
Hi, daen...@debian.org (2010-03-28 at 1513.22 +0200): On Sun, 2010-03-28 at 05:30 +0200, GSR wrote: I was reading the list of radeon reports and found yours. Time ago I experienced a problem with similar symptoms, that got fixed by adding Option MigrationHeuristic greedy (that go back to XAA, as other ^ ... that or go ... person suggested). What do you mean? That option has nothing to do with XAA. Sorry, or was missing. To sum up, I meant new EXA with greedy mode gives a similar speed than plain old XAA. GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100328164715.ga3...@crossbow.battleship
Bug#546588: Suggestion for slow radeon (debian bug 546588)
Hi: I was reading the list of radeon reports and found yours. Time ago I experienced a problem with similar symptoms, that got fixed by adding Option MigrationHeuristic greedy (that go back to XAA, as other person suggested). Maybe your case is the same. I got the idea to test that option from: http://lists.freedesktop.org/archives/xorg/2008-May/thread.html#35451 GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100328033003.ga26...@crossbow.battleship
Bug#524670: XF86VidModeGetGammaRamp errors
Hi, k...@debian.org (2010-03-03 at 0339.01 +0100): I fear you didn't receive the following message: No, and I had forgotten completly about this bug. Kevin Shanahan kmsha...@disenchant.net (13/09/2009): Hi, I came up against this error too. Just thought I'd let you know that the reason you are seeing this error is that the new xserver breaks the assumption a lot of apps make that the gamma ramp is always of size 256. Try querying the size using XF86VidModeGetGammaRampSize first and then use a buffer of the returned size to get and set the gamma. That sounds like it's not a bug in the end? To avoid messing with the arrays I tried a dirty and quick hack based in the suggested query (rewrite the define after printing what was returned). Well, it says 256 so the define is unchanged. No idea why it failed for some time, maybe then the ramp was other size in the meanwhile (bigger to support all cards, then back to what each card really does?). Anyway I will try to improve the code so the define can go away. Thanks for the tip and the reminder. GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100316213527.ga30...@crossbow.battleship
Bug#524794: libgl1-mesa-dri: OpenGL apps redraw over any other window
Hi, jcris...@debian.org (2009-11-06 at 1838.42 +0100): What's the status of this bug? Updated and the DRI info now is: OpenGL vendor string: DRI R300 Project OpenGL renderer string: Mesa DRI R300 (RV350 4152) 20090101 AGP 8x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.5 Mesa 7.6 Currently they do not redraw on top of other windows, but screen captures still cause problems (black zones for 2D apps over 3D apps, when using ImageMagick's import). Better, but still some issues. GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524794: libgl1-mesa-dri: OpenGL apps redraw over any other window
Hi: Upgraded to 7.5-2 (via 7.5-1) and things changed to slightly better as I can enable Composite extension again without suffering visible overlapping issues, but still not perfect as screenshots still show black if a 2D app overlaps the 3D one. For the record, 7.5-1 made all screen black except the mouse cursor when a 3D app was focused, and back to normal when unfocused, showing all other windows and even the 3D content fine. Composite off worked as in 7.4, but seeing there was an update ready (7.5-2) I decided to try that one before reporing this free screensaver behaviour. I just noticed there is another update (7.5-3), I will test it soon. GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531629: xkb-data: Control-Alt-Backspace (finish X11) broken with 1.6
Package: xkb-data Version: 1.6-1 Severity: normal I upgraded to 1.6-1 and Control-Alt-Backspace stopped working. Downgraded back to 1.5-2 and it works again. The xorg.conf file has the DontZap option, this is not about the sequence being disabled by default in nex Xorgs, it has been working fine for some months since I upgraded Xorg and had to add that option to the config file, it must be something specific to xkb-data 1.6. From the log, just in case options or model matters: ---8--- (II) config/hal: Adding input device AT Translated Set 2 keyboard (II) LoadModule: evdev (II) Loading /usr/lib/xorg/modules/input//evdev_drv.so (II) Module evdev: vendor=X.Org Foundation compiled for 1.6.1, module version = 2.2.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: /dev/input/event0 (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device AT Translated Set 2 keyboard (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout es (**) Option xkb_options lv3:ralt_switch_multikey,compose:menu ---8--- -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524794: libgl1-mesa-dri: OpenGL apps redraw over any other window
Hi, daen...@debian.org (2009-04-28 at 1105.49 +0200): I have been also trying other 3D apps, like Supertuxkart, and found out the one running via PLib/SDL does not cause stacking issues, just that in screenshots I get black pixels in zones covered by other windows and the 3D content in non covered parts. STK from SVN does not use SDL anymore... and the full bug appears. Does running the affected apps with XLIB_SKIP_ARGB_VISUALS=1 work around the problem? With that glxgears just prints: ---8--- Error: couldn't get an RGB, Double-buffered visual ---8--- Blender fails too: ---8--- GHOST_WindowX11.cpp:177: X11 glxChooseVisual() failed for OpenGL, verify working openGL system! X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 18 (X_ChangeProperty) Resource id in failed request: 0xb6f9a020 Serial number of failed request: 29 Current serial number in output stream: 30 ---8--- But STK from SVN (the non Plib/SDL version) works, and windows over it are not covered! It just reports: ---8--- Level 1: No doublebuffering available. ---8--- Screen captures of this STK show the 3D zone, with 2D windows over it as plain black rectangles. FPS stats are even better than before by 10 or so frames (or maybe just coincidence... the important is that speed is not a lot worse). There is also a 2D app that causes black zones in similar fashion than 3D ones (its pixels which are covered by others appear as black). It is a xterm with colour log and some settings in wm to put it below others and non focusable. The interesting part is that if the covering window is just 3D, the 3D info appears fine in the screenshots (without frames, which are 2D and appear black, like in 2D over 3D case). Maybe two bugs, or maybe all this who can paint visible or 'screenshotable' pixel is related somehow. Thanks for all the patience. GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524794: libgl1-mesa-dri: OpenGL apps redraw over any other window
, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays 16 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x82 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x83 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x84 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x85 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x86 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x87 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x88 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x89 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x8a 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x8b 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x8c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x8d 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x8e 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x71 32 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 16 GLXFBConfigs: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x72 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x73 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x74 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x75 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x76 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x77 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x78 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x79 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x7a 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x7b 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x7c 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x7d 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x7e 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x7f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x80 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x81 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow ---8--- GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524794: libgl1-mesa-dri: OpenGL apps redraw over any other window
Hi, brice.gog...@ens-lyon.org (2009-04-20 at 2105.01 +0200): Which desktop environment and window manager are you using? Can you try a dumb window manager such as twm instead? Plain Sawfish, and yes, it happens with twm too. It works when using software OpenGL (for example two X sessions, the second one fall backs to SW rasterizer). GSR -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524794: libgl1-mesa-dri: OpenGL apps redraw over any other window
Package: libgl1-mesa-dri Version: 7.4-2 Severity: important Since upgrading to 7.4, glxgears, blender and others 3D apps, always redraw on top of everything, ignoring window stacking. 2D apps are still there, just their on screen pixels have been overwritten and a redraw must be forced to appear (select text or scroll, eg). There is no composite manager running. I would try to show the artifacts, but screen captures do not show OpenGL apps, just black or data from 2D apps (again, before upgrade, capturing was possible with simple tools like ImageMagick's import). DRI is on, based in glxinfo: OpenGL vendor string: DRI R300 Project OpenGL renderer string: Mesa DRI R300 20060815 AGP 8x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 7.4 GSR -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgl1-mesa-dri depends on: ii libc6 2.9-7 GNU C Library: Shared libraries ii libdrm-intel1 2.4.9-1Userspace interface to intel-speci ii libdrm2 2.4.9-1Userspace interface to kernel DRM ii libexpat1 2.0.1-4XML parsing C library - runtime li ii libgl1-mesa-glx 7.4-2 A free implementation of the OpenG libgl1-mesa-dri recommends no packages. Versions of packages libgl1-mesa-dri suggests: pn libglide3 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524670: libxxf86vm1: Errors mentioning XFree86-VidModeExtension and XF86VidModeGetGammaRamp
Package: libxxf86vm1
Version: 1:1.0.2-1
Severity: normal
Some apps that adjust or report the gamma curves stopped working since
upgrading to xorg 7.4, they do nothing except print things like:
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 129 (XFree86-VidModeExtension)
Minor opcode of failed request: 17 (XF86VidModeGetGammaRamp)
Value in failed request: 0x17
Serial number of failed request: 8
Current serial number in output stream: 8
Example app:
---8--- invgamma.c
#include X11/Xlib.h
#include X11/extensions/Xext.h
#include X11/extensions/xf86vmode.h
#define GAMMA_COMPONENTS 3
#define GAMMA_RESOLUTION 256
/*
* Ben Winslow r...@bluecherry.net - 9/28/2001
* gcc -o invgamma invgamma.c -L/usr/X11R6/lib -lX11 -lXext -lXxf86vm
*/
int main(int argc, char *argv[])
{
Display *dpy;
unsigned short ramp_in[GAMMA_COMPONENTS][GAMMA_RESOLUTION];
unsigned short ramp_out[GAMMA_COMPONENTS][GAMMA_RESOLUTION];
int x, y;
dpy = XOpenDisplay(NULL);
if (XF86VidModeGetGammaRamp(dpy, DefaultScreen(dpy), GAMMA_RESOLUTION,
ramp_in[0], ramp_in[1], ramp_in[2]) == False)
return 1;
for (x = 0; x GAMMA_COMPONENTS; x++) {
for (y = 0; y GAMMA_RESOLUTION; y++) {
ramp_out[x][y] = ramp_in[x][(GAMMA_RESOLUTION - 1) - y];
}
}
if (XF86VidModeSetGammaRamp(dpy, DefaultScreen(dpy), GAMMA_RESOLUTION,
ramp_out[0], ramp_out[1], ramp_out[2]) == False)
return 1;
return 0;
}
---8--- invgamma.c
GSR
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.29-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libxxf86vm1 depends on:
ii libc6 2.9-7 GNU C Library: Shared libraries
ii libx11-6 2:1.2.1-1 X11 client-side library
ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar
libxxf86vm1 recommends no packages.
libxxf86vm1 suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
