Bug#404038: xserver-xorg-core: non-modular configuration scheme

[Marc Haber]

Package: xserver-xorg-core
Version: 1.1.1-12
Severity: wishlist

Hi,

for ksynaptics, I need to enter "SHMConfig on" into the touch pad
section of xorg.conf. When I do this, I lose all debian automatisms
since the xorg maintainer scripts notice that the file was manually
changed.

Please provide a means to do such local modifications (like an overlay
or an include file) without losing Debian magic.

Greetings
Marc

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19.1-zgsrv
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403975: Upgrade report, continues

[Robert de Bath]

Segfault appear to be fixed by upgrade to vesa driver that's arrived
in test today. However, the vesa driver is VERY slow compared to the
trident driver when using "mplayer" even though I've disabled XVideo
in the trident driver (mplayer window is blue when enabled).

The Trident driver also claims the display has 8192 kByte of memory,
it actually has 32768 kBytes. (It ignores a VideoRam option)

The ShadowFB makes little difference to the vesa driver (for video) but
prevents the trident driver working if it's set to yes; the screen
remains in what appears to be a corrupted "textmode". Note, however,
this is NOT actually textmode as I have a "vga=0x318" in my lilo.conf.

I've also now tried the fbdev driver; it appears to be getting the video
planes wrong in some way, I get four distorted copies of the desktop 
across the screen. (ppmtofb works fine; once package problem is overridden)


# fbsev -i
mode "1024x768-76"
# D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz
geometry 1024 768 1024 768 32
timings 12714 128 32 16 4 128 4
rgba 8/16,8/8,8/0,0/0
endmode

Frame buffer device information:
Name: VESA VGA
Address : 0xf000
Size: 6291456
Type: PACKED PIXELS
Visual  : TRUECOLOR
XPanStep: 0
YPanStep: 0
YWrapStep   : 0
LineLength  : 4096
Accelerator : No
# cat /proc/version 
Linux version 2.6.14-2-686 (Debian 2.6.14-6bpo1) ([EMAIL PROTECTED]) (gcc

version 3.3.5 (Debian 1:3.3.5-13)) #2 Fri Dec 30 03:19:34 CET 2005
#


--
Rob.  (Robert de Bath )
 # /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "Files"
FontPath"/usr/share/fonts/X11/misc"
FontPath"/usr/X11R6/lib/X11/fonts/misc"
FontPath"/usr/share/fonts/X11/cyrillic"
FontPath"/usr/X11R6/lib/X11/fonts/cyrillic"
FontPath"/usr/share/fonts/X11/100dpi/:unscaled"
FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
FontPath"/usr/share/fonts/X11/75dpi/:unscaled"
FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
FontPath"/usr/share/fonts/X11/Type1"
FontPath"/usr/X11R6/lib/X11/fonts/Type1"
FontPath"/usr/share/fonts/X11/100dpi"
FontPath"/usr/X11R6/lib/X11/fonts/100dpi"
FontPath"/usr/share/fonts/X11/75dpi"
FontPath"/usr/X11R6/lib/X11/fonts/75dpi"
# path to defoma fonts
FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
EndSection

Section "Module"
Load"bitmap"
Load"dbe"
Load"ddc"
Load"dri"
#   Load"extmod"
Load"freetype"
Load"glx"
Load"int10"
Load"record"
Load"vbe"
# This disables XVideo
 SubSection "extmod"
   Option  "omit XVideo"
   Option  "omit XVideo-MotionCompensation"
 EndSubSection

EndSection

Section "DRI"
Mode0666
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "CoreKeyboard"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc105"
Option  "XkbLayout" "gb"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/psaux"
Option  "Protocol"  "PS/2"
Option  "Emulate3Buttons"   "true"
EndSection

Section "InputDevice"
Identifier  "Synaptics Touchpad"
Driver  "synaptics"
Option  "SendCoreEvents""true"
Option  "Device""/dev/psaux"
Option  "Protocol"  "auto-dev"
Option  "HorizScrollDelta"  "0"
EndSection

Section "Device"
Identifier  "Trident Microsystems CyberBlade XP4m32"
Driver  "trident"
BusID   "PCI:1:0:0"

Option  "CyberStretch"  "yes"
#Option  "ShadowFB"  "yes"
#Option "VideoRam"  "32768"

EndSection

Section "Device"
Identifier  "VMVware

Re: Bug#347448: xlibmesa-dri: sis : sizeof(SISDRIRec) does not match passed size from device driver

[FReeZ]

Hello, i have just the same problem as described in here. My X.org version  
is 6.9.0, kernel 2.6.19.1, videocard SiS300 32MB AGP (not on board).  
OpenGL version string: 1.2 (1.5 Mesa 6.4.1).


$ export LIBGL_DEBUG=verbose
$ glxgears
libGL: XF86DRIGetClientDriverName: 0.8.1 sis (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/sis_dri.so
drmOpenByBusid: Searching for BusID pci::01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports pci::01:00.0

ERROR!  sizeof(SISDRIRec) does not match passed size from device driver
libGL warning: 3D driver returned no fbconfigs.
libGL error: InitDriver failed
libGL error: reverting to (slow) indirect rendering

My question is: how to solve it?
Thanks for any suggestions.

Bug#404079: display problem with xterm + screen and bold characters

[Vincent Lefevre]

Package: xterm
Version: 223-1
Severity: important

Not sure this is a bug in xterm, but the following problems don't occur
with rxvt.

Xterm doesn't behave correctly when there are bold characters in screen,
when using TERM=xterm-debian or TERM=xterm-xfree86, but no problem when
using TERM=xterm. It seems to be a regression (as I didn't notice this
problem before), but I'm not sure.

For instance, ssh to a Debian/stable machine, start "screen", with the
zsh shell. Set the following prompts:

  PS1="%{`tput bold`%}%% %{`tput sgr0`%}"
  RPS1="abc"

Hit [Enter] a few times and type "true", and hit [Enter] again a few
times, to have:

%   abc
%   abc
% true  abc
%   abc
%   abc

Detach the screen session and reattach it. I get:

%   bc
%   bc
% rue  abc
%   bc
%   bc

Same problem after a ssh to Mac OS X, but only with TERM=xterm-debian.
Note: like Debian/stable, Mac OS X uses ncurses 5.4.

This problem makes xterm quite unusable with screen.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686-bigmem
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages xterm depends on:
ii  libc62.3.6.ds1-9 GNU C Library: Shared libraries
ii  libfontconfig1   2.4.2-1 generic font configuration library
ii  libice6  1:1.0.1-2   X11 Inter-Client Exchange library
ii  libncurses5  5.5-5   Shared libraries for terminal hand
ii  libsm6   1:1.0.1-3   X11 Session Management library
ii  libx11-6 2:1.0.3-4   X11 client-side library
ii  libxaw7  1:1.0.2-4   X11 Athena Widget library
ii  libxext6 1:1.0.1-2   X11 miscellaneous extension librar
ii  libxft2  2.1.8.2-8   FreeType-based font drawing librar
ii  libxmu6  1:1.0.2-2   X11 miscellaneous utility library
ii  libxt6   1:1.0.2-2   X11 toolkit intrinsics library
ii  xbitmaps 1.0.1-2 Base X bitmaps

Versions of packages xterm recommends:
ii  xutils  1:7.1.ds.3-1 X Window System utility programs

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#389433: Stage 1

[Robert de Bath]

Section "Screen"
Identifier  "FB"
Device  "FB device"
Monitor "LCD"
DefaultDepth24
DefaultFbBpp32
SubSection "Display"
Depth   24
FbBpp   32
Modes   "1024x768"
EndSubSection
EndSection

If I add the FbBbp and DefaultFbBpp to xorg.conf or set the "-fbbpp 32" 
command line option the display becomes readable. BUT rotation does NOT

work, it appears that the shadowFB is not actually being used.

--
Rob.  (Robert de Bath )
 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Rob Bochan]

more info from the wine.log, every one of them shows:

libGL warning: 3D driver claims to not support visual 0x25
libGL warning: 3D driver claims to not support visual 0x26
libGL warning: 3D driver claims to not support visual 0x29
libGL warning: 3D driver claims to not support visual 0x2a
libGL warning: 3D driver claims to not support visual 0x2d
libGL warning: 3D driver claims to not support visual 0x2e
libGL warning: 3D driver claims to not support visual 0x31
libGL warning: 3D driver claims to not support visual 0x32
libGL warning: 3D driver claims to not support visual 0x35
libGL warning: 3D driver claims to not support visual 0x36
libGL warning: 3D driver claims to not support visual 0x39
libGL warning: 3D driver claims to not support visual 0x3a
libGL warning: 3D driver claims to not support visual 0x3d
libGL warning: 3D driver claims to not support visual 0x3e
libGL warning: 3D driver claims to not support visual 0x41
libGL warning: 3D driver claims to not support visual 0x42

-- 

...Rob


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Michel Dänzer]

On Thu, 2006-12-21 at 11:38 -0500, Rob Bochan wrote:
> On Thursday 21 December 2006 01:46, you wrote:
> >
> > Please provide a log file from a crash
> 
> See attached (console.log), which contains everything I could see at the 
> console after attempting to run glxgears. Using tail on Xorg.0.log file shows 
> the same exact output from a second crash from glxgears.
> 
> > and the output from LIBGL_DEBUG=verbose glxinfo
> 
> I've tried this several times, but the only thing I can get to dump to a file 
> is:
> 
> name of display: :0.0

Do these crashes also occur if you disable AIGLX with

Option  "AIGLX" "off"

in Section "ServerFlags"?


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

Bug#404090: GPU temperature skyrockets after starting X

[Alberto Gonzalez Iniesta]

Package: xserver-xorg-video-ati
Version: 1:6.6.3-2
Severity: important

Hi X Strike Force,

I'm fighting with my new (2nd hand) iBook G4 and found the following
behaviour in it:
(I don't run ?dm, the computer starts in text console mode)
- Start X, the GPU temperature starts to rise *very* quickly
- The temperature will reach 80 Celsius and fan will turn on
  (don't know how far it would go)
- No matter whether you remain in X or quit, the temperature won't
  descent

Now, if you suspend the laptop (by closing the lid) and resume
(just after a couple of secs.) not only the temperature will be
much lower, it will remain that low (~60C). That will happen
whether you suspend after quitting X OR even if you stay in X before
and after resuming.

So the problem seems to be in the initialization of the video card.

My video card conf:
Section "Device"
  Identifier  "Generic Video Card"
#  Driver  "radeon"
  Driver  "ati"
  BusID   "PCI:0:16:0"
  Option  "UseFBDev"
  "true"
  VendorName  "ATI"
# Option  "AGPMode" "4"
EndSection

I've tried both 'radeon' and 'ati' drivers and AGPMode 4 and none (1).
All with the same result. So it could be a kernel (module) problem
(2.6.19.1).

Thanks,

Alberto


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages xserver-xorg-video-ati depends on:
ii  libc62.3.6.ds1-9 GNU C Library: Shared libraries
ii  xserver-xorg-core2:1.1.1-12  X.Org X server -- core server

xserver-xorg-video-ati recommends no packages.

-- no debconf information



-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Rob Bochan]

On Thursday 21 December 2006 01:46, you wrote:
>
> Please provide a log file from a crash

See attached (console.log), which contains everything I could see at the 
console after attempting to run glxgears. Using tail on Xorg.0.log file shows 
the same exact output from a second crash from glxgears.

> and the output from LIBGL_DEBUG=verbose glxinfo

I've tried this several times, but the only thing I can get to dump to a file 
is:

name of display: :0.0

since I keep getting dumped back to the console, and I can't run glxinfo from 
there to get more info. I've attached the Xorg.0.log from that crash. If you 
know of a way I can provide more info, I'll do whatever I can.

Some notes that may or may not be relevant:
-  The crashing doesn't seem to occur on everything running under 
winex/cedega. I am able to successfully run an old copy of Irfanview and 
Forte Agent. Running Diablo 2 crashes the X server.
-  I am also noticing the crashes whenever I try to run any applications under 
wine (tested Forte Agent and Irfanview mentioned above, and IE6).
-  Crash occurs if I try to access the "OpenGL" section of KDE's KInfoCenter.
-  I'm also noticing some other "artifacts" from within KDE, like system tray 
icons blinking (not because of activity) and slow scrolling with apps like web 
browsers.
-  All this behavior is present with root as well as normal users.

-- 

...Rob
...
(==) Using config file: "/etc/X11/xorg.conf"

	xkb_keycodes			{ include "xfree86+aliases(qwerty)" };
	xkb_types			{ include "complete" };
	xkb_compatibility		{ include "complete" };
	xkb_symbols			{ include "pc(pc105)+us" };
	xkb_geometry			{ include "pc(pc104)" };
DRIUnlock called when not locked
	xkb_types			{ include "%" };
	xkb_compatibility		{ include "%" };
	xkb_symbols			{ include "%" };
	xkb_geometry			{ include "%" };
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error:			Missing KeyNames section in a Keymap file
>Description of Keymap not compiled
Errors from xkbcomp are not fatal to the X server
(EE) Error loading keymap /var/tmp/server-0.xkm

Backtrace:
0: /usr/bin/X11/X(xf86Sighandler+0x84) [0x80c4354]
1: [0xb7fd4420]
2: /usr/lib/xorg/modules/extensions/libglx.so [0xb7cbbba]
3: /usr/lib/xorg/modules/extensions/libglx.so(DoMakeCurrent+0x3bc) [0xb7c95ebc]
4: /usr/lib/xorg/modules/extensions/libglx.so(__glXMakeCurrent+0x39) [0xb7c96069]
5: /usr/lib/xorg/modules/extensions/libglx.so [0xb7c98f6a]
6: /usr/bin/X11/X(Dispatch+0x19b) [0x8086cab]
7: /usr/bin/X11/X(main+0x489) [0x806e699]
8: /lib/tls/libc.so.6(__libc_start_main+0xc8) [0xb7ddcea8]
9: /usr/bin/X11/X(FontFileCompleteXLFD+0xa9) [0x806d9d1]

Fatal server error:
Caught signal 11.  Server aborting

xinit:  connection to X server lost.

X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: UNKNOWN 
Current Operating System: Linux blah 2.6.18-3-k7 #1 SMP Sun Dec 10 20:17:39 UTC 2006 i686
Build Date: 13 December 2006
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 21 11:08:06 2006
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) |   |-->Monitor "Diamond Pro 710"
(**) |   |-->Device "3Dfx Interactive, Inc. Voodoo 4 / Voodoo 5"
(**) |-->Input Device "Generic Keyboard"
(**) |-->Input Device "Configured Mouse"
(WW) The directory "/usr/X11R6/lib/X11/fonts/misc" does not exist.
	Entry deleted from font path.
(WW) The directory "/usr/X11R6/lib/X11/fonts/cyrillic" does not exist.
	Entry deleted from font path.
(WW) The directory "/usr/X11R6/lib/X11/fonts/100dpi/" does not exist.
	Entry deleted from font path.
(WW) The directory "/usr/X11R6/lib/X11/fonts/75dpi/" does not exist.
	Entry deleted from font path.
(WW) The directory "/usr/X11R6/lib/X11/fonts/Type1" does not exist.
	Entry deleted from font path.
(WW) The directory "/usr/X11R6/lib/X11/fonts/100dpi" does not exist.
	Entry deleted from font path.
(WW) The directory "/usr/X11R6/lib/X11/fonts/75dpi" does not exist.
	Entry deleted from font path.
(**) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/cyrillic,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.3
	X.Org Video Driver: 1.0
	X.Org XInput driver : 0.6
	X.Org Server Extension : 0.3
	X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModul

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Michel Dänzer]

On Thu, 2006-12-21 at 12:32 -0500, Rob Bochan wrote:
> more info from the wine.log, every one of them shows:
> 
> libGL warning: 3D driver claims to not support visual 0x25

[...]

See https://bugs.freedesktop.org/show_bug.cgi?id=6689 .


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Michel Dänzer]

On Thu, 2006-12-21 at 12:59 -0500, Rob Bochan wrote:
> On Thursday 21 December 2006 12:33, you wrote:
> >
> > Do these crashes also occur if you disable AIGLX with
> >
> > Option  "AIGLX" "off"
> >
> > in Section "ServerFlags"?
> 
> No they do not, 

Then apparently the tdfx 3D driver is incompatible with AIGLX.

> though I had to add that section to the xorg.conf manually. 
> The glxgears and glxinfo programs run, as do some of the wine programs 
> mentioned above, but not the game via winex.

This might be due to the lack of direct rendering.

> The output of
> LIBGL_DEBUG=verbose glxinfo
> is attached (glxinfo.log).

The stderr output is missing, so it's not clear why direct rendering is
not being used.


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Rob Bochan]

On Thursday 21 December 2006 12:33, you wrote:
>
> Do these crashes also occur if you disable AIGLX with
>
>   Option  "AIGLX" "off"
>
> in Section "ServerFlags"?

No they do not, though I had to add that section to the xorg.conf manually. 
The glxgears and glxinfo programs run, as do some of the wine programs 
mentioned above, but not the game via winex.
The output of
LIBGL_DEBUG=verbose glxinfo
is attached (glxinfo.log).

-- 

...Rob
name of display: :0.0
display: :0  screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, 
GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, 
GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.5.1)
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, 
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, 
GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, 
GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 
GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, 
GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, 
GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, 
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, 
GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 
GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, 
GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, 
GL_EXT_secondary_color, GL_EXT_separate_specular_color, 
GL_EXT_shadow_funcs, 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_lod_bias, GL_EXT_texture_object, 
GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, 
GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, 
GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, 
GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, 
GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection, 
GL_NV_texture_rectangle, 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, 
GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

   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
--
0x23 16 tc  0 16  0 r  .  .  5  6  5  0  0  0  0  0  0  0  0  0 0 None
0x24 16 tc  0 16  0 r  .  .  5  6  5  0  0  0  8  0  0  0  0  0 0 Slow
0x25 16 tc  0 16  0 r  .  .  5  6  5  0  0  0  0 16 16 16  0  0 0 Slow
0x26 16 tc  0 16  0 r  .  .  5  6  5  0  0  0  8 16 16 16  0  0 0 Slow
0x27 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x28 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  8  0  0  0  0  0 0 Slow
0x29 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x2a 16 tc  0 16  0 r  .  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow
0x2b 16 tc  0 16  0 r  y  .  5  6  5  0  0  0  0  0  0  0  0  0 0 None
0x2c 16 tc  0 16  0 r  y  .  5  6  5  0  0  0  8  0  0  0  0  0 0 Slow
0x2d 16 tc  0 16  0 r  y  .  5  6  5  0  0  0  0 16 16 16  0  0 0 Slow
0x2e 16 tc  0 16  0 r  y  .  5  6  5  0  0  0  8 16 16 16  0  0 0 Slow
0x2f 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x30 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  8  0  0  0  0  0 0 Slow
0x31 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Rob Bochan]

On Thursday 21 December 2006 13:03, you wrote:
> On Thu, 2006-12-21 at 12:59 -0500, Rob Bochan wrote:
> > On Thursday 21 December 2006 12:33, you wrote:
> > > Do these crashes also occur if you disable AIGLX with
> > >
> > >   Option  "AIGLX" "off"
> > >
> > > in Section "ServerFlags"?
> >
> > No they do not,
>
> Then apparently the tdfx 3D driver is incompatible with AIGLX.
>
> > though I had to add that section to the xorg.conf manually.
> > The glxgears and glxinfo programs run, as do some of the wine programs
> > mentioned above, but not the game via winex.
>
> This might be due to the lack of direct rendering.

Okay, what can be done about this? Things were working well before I'd 
restarted my X session yesterday. Like I mentioned previously, I hadn't 
restarted it in quite a while, even though I'd noticed some xorg upgrades 
over the last month or so. Mostly because I had been bitten by this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389781
previously, and I'm now a bit paranoid about not having a properly working x 
server.

> > The output of
> > LIBGL_DEBUG=verbose glxinfo
> > is attached (glxinfo.log).
>
> The stderr output is missing, so it's not clear why direct rendering is
> not being used.

If you can tell me how to get that to you, I'd be glad to do so.

-- 

...Rob


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404108: mesa-utils: glxinfo crashes in Xephyr

[Stepan Golosunov]

Package: mesa-utils
Version: 6.3.2-2.1
Severity: normal

When run in Xephyr glxinfo crashes:

% glxinfo
name of display: :2.0
Error: couldn't find RGB GLX visual

   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
--
zsh: segmentation fault  glxinfo



-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)

Versions of packages mesa-utils depends on:
ii  freeglut32.4.0-5 OpenGL Utility Toolkit
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  libgl1-mesa-glx [libgl1] 6.5.1-0.4   A free implementation of the OpenG
ii  libglu1-mesa [libglu1]   6.5.1-0.4   The OpenGL utility library (GLU)
ii  libx11-6 2:1.0.3-4   X11 client-side library

mesa-utils recommends no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404111: xterm: FTBFS on GNU/kFreeBSD

[Petr Salinger]

Package: xterm
Severity: important
Version: 223-1
Tags: patch


Hi,


the current version fails to build on GNU/kFreeBSD.

It needs small tweaks, see attached patch.

It would also be nice if you can ask upstream
to include this changes.

Thanks in advance

Petr

only in patch2:
unchanged:
--- xterm-223.orig/aclocal.m4
+++ xterm-223/aclocal.m4
@@ -2276,7 +2276,7 @@
 irix[[56]].*) #(vi
CPPFLAGS="$CPPFLAGS -D_SGI_SOURCE"
;;
-linux*|gnu*) #(vi
+linux*|gnu*|k*bsd*-gnu) #(vi
CF_GNU_SOURCE
;;
 mirbsd*) #(vi
only in patch2:
unchanged:
--- xterm-223.orig/configure
+++ xterm-223/configure
@@ -2827,7 +2827,7 @@
 irix[56].*) #(vi
CPPFLAGS="$CPPFLAGS -D_SGI_SOURCE"
;;
-linux*|gnu*) #(vi
+linux*|gnu*|k*bsd*-gnu) #(vi
 
 echo "$as_me:2832: checking if we must define _GNU_SOURCE" >&5
 echo $ECHO_N "checking if we must define _GNU_SOURCE... $ECHO_C" >&6
only in patch2:
unchanged:
--- xterm-223.orig/main.c
+++ xterm-223/main.c
@@ -3449,7 +3449,7 @@
/* make /dev/tty work */
ioctl(ttyfd, TCSETCTTY, 0);
 #endif
-#if defined(__GNU__) && defined(TIOCSCTTY)
+#if ((defined(__GLIBC__) && defined(__FreeBSD_kernel__)) || defined(__GNU__)) 
&& defined(TIOCSCTTY)
/* make /dev/tty work */
ioctl(ttyfd, TIOCSCTTY, 0);
 #endif

Bug#404124: when installing xserver-xorg into a chroot, screen blanks

[Vagrant Cascadian]

Package: xserver-xorg
Version: 1:7.1.0-8
Severity: normal

when attempting to install xserver-xorg into a chroot environment(while
running in a rxvt-unicode x-terminal-emulator), the screen blanks for
about 1 second right around here:

Setting up xserver-xorg (7.1.0-8) ...
xserver-xorg postinst warning: failed to infer keyboard layout from
layout/lang
   '10 debian-installer/keymap doesn't exist--en_US'

the screen returns to normal shortly after, and while it doesn't seem to
actually cause any problems, the sudden blanking of the screen is a
little alarming.

live well,
  vagrant


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Dupe, in X server, fixed

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> package xscreensaver
Ignoring bugs not assigned to: xscreensaver

> reassign 397067 xserver-xorg-core
Bug#397067: xscreensaver: Crashes immediately: Failed RRSelectInput on AMD64 
with PPC X server
Bug reassigned from package `xscreensaver' to `xserver-xorg-core'.

> package xserver-xorg-core
Ignoring bugs not assigned to: xserver-xorg-core

> close 397067
Bug#397067: xscreensaver: Crashes immediately: Failed RRSelectInput on AMD64 
with PPC X server
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to "J.P. Larocque" <[EMAIL PROTECTED]>

> merge 397067 291100
Bug#291100: XRandR extension has endianess issues
Bug#397067: xscreensaver: Crashes immediately: Failed RRSelectInput on AMD64 
with PPC X server
Merged 291100 397067.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

xserver-xorg-video-vesa 1:1.3.0-1 MIGRATED to testing

[Debian testing watch]

FYI: The status of the xserver-xorg-video-vesa source package
in Debian's testing distribution has changed.

  Previous version: 1:1.2.1-3
  Current version:  1:1.3.0-1

-- 
This email is automatically generated; [EMAIL PROTECTED] is responsible.
See http://people.debian.org/~henning/trille/ for more information.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404079: display problem with xterm + screen and bold characters

[Thomas Dickey]

On Thu, Dec 21, 2006 at 07:00:15PM +0100, Vincent Lefevre wrote:
> Package: xterm
> Version: 223-1
> Severity: important
> 
> Not sure this is a bug in xterm, but the following problems don't occur
> with rxvt.

This sounds like (see http://invisible-island.net/ncurses/NEWS.gz)

20040710
+ modify logic in tgetent() which adjusts the termcap "me" string  
  to work with ISO-2022 string used in xterm-new (cf: 20010908).

also note the followups for sgr0 in that file.

> Xterm doesn't behave correctly when there are bold characters in screen,
> when using TERM=xterm-debian or TERM=xterm-xfree86, but no problem when
> using TERM=xterm. It seems to be a regression (as I didn't notice this
> problem before), but I'm not sure.

rxvt behaves different since it has different error detection for the
control sequences (this is not saying that it's behaving correctly ;-).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpJx8KIwjCUo.pgp
Description: PGP signature

Bug#404111: xterm: FTBFS on GNU/kFreeBSD

[Thomas Dickey]

On Thu, Dec 21, 2006 at 09:50:16PM +0100, Petr Salinger wrote:
> Package: xterm
> Severity: important
> Version: 223-1
> Tags: patch
...
> the current version fails to build on GNU/kFreeBSD.
> 
> It needs small tweaks, see attached patch.
> 
> It would also be nice if you can ask upstream
> to include this changes.

thanks

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpEEpKA4TFlV.pgp
Description: PGP signature

Re: X Strike Force X.Org X11 SVN commit: r4161 - trunk/debian/xorg/debian

[David Nusinow]

On Thu, Dec 21, 2006 at 07:53:00AM +0100, Michel Dänzer wrote:
> On Wed, 2006-12-20 at 22:30 -0500, David Nusinow wrote:
> > On Wed, Dec 20, 2006 at 08:47:11AM +0100, Michel Dänzer wrote:
> > > On Tue, 2006-12-19 at 22:18 -0500, X Strike Force SVN Repository Admin
> > > wrote:
> > > > 
> > > > * Move the depends on xserver-xorg-(input/video)-all to a recommends. 
> > > > Just
> > > >   depend on the pseudopackages. The recommends also | -vesa for video, 
> > > > and
> > > >   -kbd and -mouse for -input. We duplicate the recommendation for
> > > >   xserver-xorg-input-all to handle the two different input packages we 
> > > > need.
> > > >   This is to deal with issues in which aptitude can't install the -all
> > > >   packages, so it just picks something random. This gives it some hints,
> > > >   hopefully at least guaranteeing that -vesa, -kbd, and -mouse are
> > > >   installed.
> > > 
> > > The vesa driver doesn't work on most non-x86 machines...
> > 
> > Well, that option is meant to be a failsafe when the xserver-xorg-video-all
> > package fails to install for whatever reason. Do you have any ideas for a
> > better failsafe option that could cover us better across more arches?
> 
> There is no single 'failsafe' driver. Where vesa doesn't work, fbdev
> might (ignoring its current ShadowFB breakage...), but in some cases
> even vga or something else might be necessary.

I'm considering setting an arch-specific variable for the fail-safe option,
like we currently do to define the various -all packages. It's not likely
for etch, but it might be helpful in the future. What do you think?

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404038: xserver-xorg-core: non-modular configuration scheme

[David Nusinow]

On Thu, Dec 21, 2006 at 11:09:48AM +0100, Marc Haber wrote:
> Package: xserver-xorg-core
> Version: 1.1.1-12
> Severity: wishlist
> 
> Hi,
> 
> for ksynaptics, I need to enter "SHMConfig on" into the touch pad
> section of xorg.conf. When I do this, I lose all debian automatisms
> since the xorg maintainer scripts notice that the file was manually
> changed.
> 
> Please provide a means to do such local modifications (like an overlay
> or an include file) without losing Debian magic.

It's most likely that we'll be abandoning the debconfage all together over
the next development cycle. Upstream development is heading towards dynamic
reconfiguration for everything we really care about, and all the rest can
simply be set to reasonable defaults in the server so we don't even need an
xorg.conf under normal circumstances. That'll make the overlay unnecessary,
but spirit of the idea is the same. Thanks for your report!

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian XSF SVN to git migration

[David Nusinow]

On Tue, Dec 19, 2006 at 02:32:48PM +0100, Thierry Reding wrote:
> First of all is the question of the repository layout. What was clear from
> the start is that we'd like to mirror the directory structure from upstream.
> The second issue is what to do with the upstream sources. So far the
> alternatives we've been discussing are 1) having selected upstream branches
> cloned into our repositories and 2) leaving it up to the packager to use
> upstream branches in their local clones of the Debian repositories. Does any
> of these alternatives have a significant advantage over the other? Is there
> perhaps a different approach that would work even better?

To me, the most important thing is consistency. Having to do two or three
different things depending on the packager is just going to be an
irritating barrier to getting anything done, especially if we want to
attract new people. From my experience, we definitely want to keep
attracting people.

Also, I'm in favor of option 1 myself. Given the toolset, it seems to be
the easiest option and the one with the least surprise. There's several
advantages to it that I see:

 1) Anyone who clones our repository will get the whole source code, making
it easier to see what's going on. It also makes it easier to do work on
the package right away. Encouraging people who aren't normally involved
to get involved, if for nothing else than to submit a single patch, is
something we should place as a high priority. It also has the side
benefit of helping ensure that we all have the same repositories.

 2) It allows us to easily cherry-pick from upstream. If we don't keep the
source tree in the repo, we have to apply all changes using quilt the
way we do now. This is extra hassle, and it's kind of silly given that
we don't need to keep these patches separate from the mainline codebase
across upstream revisions, which really is the primary benefit from
using quilt.

Now for the other option, keeping just the debian directory in the repo by
default. The advantages that I see for this are

 1) Less to download for the user who just wants to look at the packaging.
Honestly though, I see this as a very small gain because most people
will probably be interested in the code. The alioth guys don't have a
problem with us keeping the whole repo there, so server space isn't an
issue. And as keithp likes to harp on, disk space is cheap :-)

 2) Fairly simple integration in to existing git repos. This is similar to
the first, in that x.org developers who already have upstream git
checkouts need only add our repo to their remotes and check out the
minimum necessary to build the debian package. Then they can do
whatever customization they like. Again, this is a minimal gain,
and can be potentially harmful since we aren't ensuring that that
person has what the packaging claims by default.

I was actually pretty well in favor of this option originally, but after
exploring the actual mechanics of how it would work, I think importing the
source in to our repo is a good idea. git-buildpackage requires you to
import the source in to the repo anyway (git-import-orig does this) and
then merges it to master to build, so our scripting requires the source to
be in the tree anyhow. My feeling is that we should just do this once and
keep it in the repo so everyone building the package doesn't have to repeat
the work.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian XSF SVN to git migration

[David Nusinow]

On Wed, Dec 20, 2006 at 10:28:07PM -0500, David Nusinow wrote:
> On Wed, Dec 20, 2006 at 01:02:45PM +0100, Thierry Reding wrote:
> > * Otavio Salvador wrote:
> > > That means we'll stop to use the quilt to manage the patches and leave
> > > git to manage all delta between Debian and original upstream code?
> > 
> > That is still something that's up for discussion. I think stgit was being
> > considered as an alternative to quilt for managing the Debian-specific
> > patches. As I understand it, it's pretty much the same as quilt only it's
> > using git as backend.
> 
> When we last had this discussion[0], everyone was in favor of keeping the
> quilt system. No one really spoke up in favor of stgit, although it was
> listed as an option. Given that discussion, and a currently working patch
> system with quilt, I think we should keep using quilt.
> 
>  - David Nusinow
> 
> [0] http://lists.debian.org/debian-x/2006/08/msg00110.html

Looking at this again, let's do a more serious analysis before making rash
decisions.

The benefits of quilt:

 1) We already know it works and works well. We've had no problems related
to quilt since we adopted it. stgit is an unknown at this point.
 2) We already have both our own and the quilt package's makefile stuff
written
 3) Because of (2) we can easily customize it to fit our needs. This allows
things like patch-audit (I'm not sure if stgit can be customized this
easily. Does anyone else know?)
 4) quilt has become more popular, and so it's generally well known to the
general developer population
 5) Each patch is a file, which makes it very easy to extract them for
things like emailing them. It's also trivial to see which patches we
apply simply by looking at git.debian.org
 6) quilt is somewhat transparent because of this. Anyone can look in
debian/patches and see what we're applying. They have to know that this
exists though.

Now the benefits of stgit:

 1) Integrates very nicely with git. Having it as an extension to the git
interface is really lovely.
 2) Probably more transparent to upstream or other people less familiar
with Debian packaging. Just tell them that debian-specific patches are
in stgit, and they already know the interface to use it. 
 3) Working with it day to day will probably be a lot easier than using
quilt. quilt requires you to set an environment variable to tell it
where the patches directory is, and so forth, or use the symlink scheme
like we currently have. stgit just works.
 4) The .diff.gz becomes easier to read. Rather than looking at diffs of
diffs like the current scheme, you just look at a diff.
 5) No makefile stuff! We'll probably have to adapt git-buildpackage to
automagically push all the patches before building, but this should be
trivial.
 6) Integrates very nicely with qgit (though not gitk yet).

It's a tough choice. The ease of use of stgit sounds really nice to me, but
I also love the transparency that having the patches in a location like
debian/patches affords us. I'm not horribly worried about that though, but
it is a real benefit. We can get around that by artificially exporting all
the patches to debian/patches. It's more work, although I'd be happy to
write a simple script to do this. My feeling is that this would be the best
of both worlds. What do you guys think?

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#404090: GPU temperature skyrockets after starting X

[Michel Dänzer]

On Thu, 2006-12-21 at 17:37 +0100, Alberto Gonzalez Iniesta wrote:
> 
> I'm fighting with my new (2nd hand) iBook G4 and found the following
> behaviour in it:
> (I don't run ?dm, the computer starts in text console mode)
> - Start X, the GPU temperature starts to rise *very* quickly
> - The temperature will reach 80 Celsius and fan will turn on
>   (don't know how far it would go)
> - No matter whether you remain in X or quit, the temperature won't
>   descent

If

Option  "DynamicClocks"

doesn't help, please provide the full X log file.


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

Bug#403969: xserver-xorg: xserver crashing, mode related?

[Michel Dänzer]

On Thu, 2006-12-21 at 13:33 -0500, Rob Bochan wrote:
> 
> > > The output of
> > > LIBGL_DEBUG=verbose glxinfo
> > > is attached (glxinfo.log).
> >
> > The stderr output is missing, so it's not clear why direct rendering is
> > not being used.
> 
> If you can tell me how to get that to you, I'd be glad to do so.

Try

LIBGL_DEBUG=verbose glxinfo 2>&1 >/dev/null


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

Re: X Strike Force X.Org X11 SVN commit: r4161 - trunk/debian/xorg/debian

[Michel Dänzer]

On Thu, 2006-12-21 at 20:57 -0500, David Nusinow wrote:
> On Thu, Dec 21, 2006 at 07:53:00AM +0100, Michel Dänzer wrote:
> > On Wed, 2006-12-20 at 22:30 -0500, David Nusinow wrote:
> > > On Wed, Dec 20, 2006 at 08:47:11AM +0100, Michel Dänzer wrote:
> > > > 
> > > > The vesa driver doesn't work on most non-x86 machines...
> > > 
> > > Well, that option is meant to be a failsafe when the 
> > > xserver-xorg-video-all
> > > package fails to install for whatever reason. Do you have any ideas for a
> > > better failsafe option that could cover us better across more arches?
> > 
> > There is no single 'failsafe' driver. Where vesa doesn't work, fbdev
> > might (ignoring its current ShadowFB breakage...), but in some cases
> > even vga or something else might be necessary.
> 
> I'm considering setting an arch-specific variable for the fail-safe option,
> like we currently do to define the various -all packages. It's not likely
> for etch, but it might be helpful in the future. What do you think?

Certainly sounds better than just vesa. :)


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer