Bug#285874: xbase-clients: "xmodmap -pk" prints only two mappings per key

[Kalle Hasselstrom]

Package: xbase-clients
Version: 4.3.0.dfsg.1-9
Severity: normal


xmodmap -pk is supposed to write a table of the current key map. It
does this, except that it only prints the first two keysymnames for
each keycode -- the last two, those that are reached by pressing
Mode_Switch, are not printed. This causes problems when I use xmodmap
-pke to save the current keymap, and later try to restore it.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-686
Locale: LANG=en_US, LC_CTYPE=sv_SE (charmap=ISO-8859-1)

Versions of packages xbase-clients depends on:
ii  cpp   4:3.3.5-1  The GNU C preprocessor (cpp)
ii  libc6 2.3.2.ds1-19   GNU C Library: Shared libraries an
ii  libdps1   4.3.0.dfsg.1-9 Display PostScript (DPS) client li
ii  libexpat1 1.95.8-1   XML parsing C library - runtime li
ii  libfontconfig12.2.3-4generic font configuration library
ii  libfreetype6  2.1.7-2.3  FreeType 2 font engine, shared lib
ii  libgcc1   1:3.4.3-4  GCC support library
ii  libice6   4.3.0.dfsg.1-9 Inter-Client Exchange library
ii  libncurses5   5.4-4  Shared libraries for terminal hand
ii  libpng12-01.2.8rel-1 PNG library - runtime
ii  libsm64.3.0.dfsg.1-9 X Window System Session Management
ii  libstdc++51:3.3.5-3  The GNU Standard C++ Library v3
ii  libxaw7   4.3.0.dfsg.1-9 X Athena widget set library
ii  libxcursor1   1.1.3-1X cursor management library
ii  libxext6  4.3.0.dfsg.1-9 X Window System miscellaneous exte
ii  libxft2   2.1.2-6FreeType-based font drawing librar
ii  libxi64.3.0.dfsg.1-9 X Window System Input extension li
ii  libxmu6   4.3.0.dfsg.1-9 X Window System miscellaneous util
ii  libxmuu1  4.3.0.dfsg.1-9 lightweight X Window System miscel
ii  libxpm4   4.3.0.dfsg.1-9 X pixmap library
ii  libxrandr24.3.0.dfsg.1-9 X Window System Resize, Rotate and
ii  libxrender1   0.8.3-7X Rendering Extension client libra
ii  libxt64.3.0.dfsg.1-9 X Toolkit Intrinsics
ii  libxtrap6 4.3.0.dfsg.1-9 X Window System protocol-trapping 
ii  libxtst6  4.3.0.dfsg.1-9 X Window System event recording an
ii  libxv14.3.0.dfsg.1-9 X Window System video extension li
ii  xlibmesa-gl [libgl1]  4.3.0.dfsg.1-9 Mesa 3D graphics library [XFree86]
ii  xlibmesa-glu [libglu1]4.3.0.dfsg.1-9 Mesa OpenGL utility library [XFree
ii  xlibs 4.3.0.dfsg.1-9 X Keyboard Extension (XKB) configu
ii  xlibs-data4.3.0.dfsg.1-9 X Window System client data
ii  zlib1g1:1.2.2-4  compression library - runtime

-- debconf information:
* xbase-clients/default_100dpi:
* xbase-clients/default_nolisten_tcp:

Bug#285871: xdm logrotate script eats logs

[Andrew Suffield]

Package: xdm
Severity: important

/etc/logrotate.d/xdm manages to delete the /var/log/xdm.log currently
in use, and never signals xdm to reopen its log file. Since xdm
usually stays running for weeks at a time, and the log is 'rotated'
daily, this means that most of the time xdm is writing to a deleted
file. Which is less than helpful.

That's the worst logrotate file I've seen in quite a while.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Bug#285861: x errors while using kernel 2.6, can't find /dev/agpgart

[E. A. Zen]

Package: xbase-clients
Version: 4.3.0.1

I have both 2.4 and 2.6*, and I typically update only once a week*, BUT  
it was only after this last update that X wouldn't run.  (output found  
at end)



I'm guessing previous versions checked which kernel was in use (thus  
saving me from the /dev/*-related problems)?  Could that be done, (or  
has it already)?



I've not upped the severity because this would only affect people with  
both kernels on a single system (silly us).


If you felt I've skimped on any information, I'll send everything but  
my mother's maiden name and my credit card number.



*2.4 and 2.6: there have been other problems I've had to work around.
*once a week: That is to say, all packages are uptodate as of the 12th.

-Eric



(II) I810(0): Ranges: V min: 50  V max: 120 Hz, H min: 30  H max: 70  
kHz, PixClock max 110 MHz

(--) I810(0): Chipset: "i810e"
(--) I810(0): Linear framebuffer at 0xF800
(--) I810(0): IO registers at addr 0xFFA8
(EE) GARTInit: Unable to open /dev/agpgart (No such device)
(EE) I810(0): AGP GART support is not available.  Make sure your kernel  
has

agpgart support or that the agpgart kernel module is loaded.
(II) UnloadModule: "i810"
(II) UnloadModule: "ddc"
(II) Unloading /usr/X11R6/lib/modules/libddc.a
(II) UnloadModule: "int10"
(II) Unloading /usr/X11R6/lib/modules/linux/libint10.a
(II) UnloadModule: "vbe"
(II) Unloading /usr/X11R6/lib/modules/libvbe.a
(II) UnloadModule: "vgahw"
(II) Unloading /usr/X11R6/lib/modules/libvgahw.a
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Bug#284965: Further Information on Bug#284965

[Alan McConnell]

By some adroit googling, I ran across the suggestion: remove the
option "Use FBDev".  So I commented this out, and lo!  I got a nice
X11 display, with Gnome etc.

However, this is still flakey.  After a period of between one and
three minutes, the display hangs.  The mouse freezes and I must
Crtl-Alt-Backspace to get back to my console.

I enclose, below, the most recent /var/log/XFree86.0.log, and my
/etc/X11/XF86Config-4.

As a newbie to Debian, I shall be grateful for any help.

Alan 

(start)--

This is a pre-release version of XFree86, and is not supported in any
way.  Bugs may be reported to XFree86@XFree86.Org and patches submitted
to [EMAIL PROTECTED]  Before reporting bugs in pre-release versions,
please check the latest version in the XFree86 CVS repository
(http://www.XFree86.Org/cvs)

XFree86 Version 4.1.0.1 / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: 21 December 2001
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems.  (See http://www.XFree86.Org/FAQ)
Build Operating System: Linux 2.6.9-rc1 i686 [ELF] 
Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Wed Dec 15 16:40:49 2004
(==) Using config file: "/etc/X11/XF86Config-4"
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) |   |-->Monitor "AOC LM720"
(**) |   |-->Device "Generic Video Card"
(**) |-->Input Device "Generic Keyboard"
(**) Option "XkbRules" "xfree86"
(**) XKB: rules: "xfree86"
(**) Option "XkbModel" "pc104"
(**) XKB: model: "pc104"
(**) Option "XkbLayout" "us"
(**) XKB: layout: "us"
(==) Keyboard: CustomKeycode disabled
(**) |-->Input Device "Configured Mouse"
(**) |-->Input Device "Generic Mouse"
(**) FontPath set to 
"unix/:7100,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/cyrillic,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi"
(==) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7

(WW) Cannot open APM
(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.1
XFree86 Video Driver: 0.4
XFree86 XInput driver : 0.2
XFree86 Server Extension : 0.1
XFree86 Font Renderer : 0.2
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
compiled for 4.1.0.1, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.2
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
compiled for 4.1.0.1, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.4
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1106,0305 card , rev 03 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1106,8305 card , rev 00 class 06,04,00 hdr 01
(II) PCI: 00:07:0: chip 1106,0686 card 1106, rev 40 class 06,01,00 hdr 80
(II) PCI: 00:07:1: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00
(II) PCI: 00:07:2: chip 1106,3038 card 0925,1234 rev 1a class 0c,03,00 hdr 00
(II) PCI: 00:07:3: chip 1106,3038 card 0925,1234 rev 1a class 0c,03,00 hdr 00
(II) PCI: 00:07:4: chip 1106,3057 card 1106,3057 rev 40 class 06,80,00 hdr 00
(II) PCI: 00:07:5: chip 1106,3058 card 1106,3058 rev 50 class 04,01,00 hdr 00
(II) PCI: 00:09:0: chip 10ec,8139 card 10ec,8139 rev 10 class 02,00,00 hdr 00
(II) PCI: 01:00:0: chip 10de,0110 card , rev b2 class 03,00,00 hdr 00
(II) PCI: End of PCI scan
(II) LoadModule: "scanpci"
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor="The XFree86 Project"
compiled for 4.1.0.1, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.4
(II) UnloadModule: "scanpci"
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(II) Host-to-PCI bridge:
(II) PCI-to-ISA bridge:
(II) PCI-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set)
(II) Bus 0 I/O range:
[0] -1 00x - 0x (0x1) IX[B]
(II) Bus 0 non-prefetchable memory range:
[0] -1 00x - 0x (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
[0] -1 00x - 0x (0x0) MX[B]
(II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0c (VGA_EN is

Bug#280457: xterm: Save terminal data when X connection is lost

[Vincent Lefevre]

On 2004-12-15 14:59:14 -0500, Branden Robinson wrote:
> Output streams from character devices are not the same sort of
> "data" for the purpose of bug severities as the contents of a
> filesystem.

OK.

> > The (only?) big problem with screen is that one cannot scrollback
> > with the mouse.
> 
> If screen is linked against ncurses, it may be a "simple mattter of
> programming" to enable sensitivity to mouse actions for it,
> similarly to lynx.

But that would not be as good as real scrolling, using a real scrollbar.

> > Hasn't this primary selection problem just been fixed as a consequence
> > of the fix for bug 277832?
> 
> I'm not convinced yet that it has been fixed to my personal satisfaction.

True. Once I could try, I didn't see any difference. That's why
I reopened the bug.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: DRI and multiple X servers

[Tomas Nykung]

On Wed, Dec 15, 2004 at 03:40:47PM -0500, Dan Christensen wrote:
> 
> You can put 
> 
>-xf86config XF86Config-4.dri
> 
> at the end of the :0 line and alter the config files so just this one
> has DRI loaded.
> 
> I'd also like it if the order in which multiple X servers started
> was more consistent.
> 
> Dan

Well, this was the kind of solution I was searching for, Thanks a lot!
Now I just need to teach the kids to always press Ctrl+Alt+F7 before
logging in and attempting to run any 3D game :)


Tomas

Bug#176091: Please update your file!

[Paul Blackman]

Hi,
offers start at as low as 3.016. Free No Obligation Fast,Professional Service
Approval in as little as 24 hours.
 

Http://www.north.takes.it

Thanks,
Paul Blackman
offers manager, 

Bug#170934: Update it now before it's too late!

[Kenton Dahl]

Dear Rena,

Some time ago you completed a form on the internet requesting help with 
re-financing your home. Since then we have not heard from you. 
Either if you have already re-financed or have not yet found what you are 
looking for, you may want to take a look at our website,
our offers start at as low as 3.098 Our form gives you the convenience of 
choosing which monthly payment is best for you depending on your circumstances.
This flexibility allows you to accelerate your payment in months where money is 
no problem, and at other times choose an option such as interest only,
and pay hudreds less. In any event, if you have a credit score of 450 or more, 
our form will be right for you, and save you hundreds of dollars each and every 
month! plus free quota right now

Http://www.north.takes.it

Sincerely,
Kenton Dahl 
financing manager, 

Bug#199032: Urgent:Update your file now!

[Elba Bolton]

Dear Joann,

Some time ago you completed a form on the internet requesting help with 
re-financing your home. Since then we have not heard from you. 
Either if you have already re-financed or have not yet found what you are 
looking for, you may want to take a look at our website,
our offers start at as low as 3.008 Our form gives you the convenience of 
choosing which monthly payment is best for you depending on your circumstances.
This flexibility allows you to accelerate your payment in months where money is 
no problem, and at other times choose an option such as interest only,
and pay hudreds less. In any event, if you have a credit score of 450 or more, 
our form will be right for you, and save you hundreds of dollars each and every 
month! plus free quota right now

Http://www.abc.understands.it

Sincerely,
Elba Bolton 
financing manager, 

Bug#280738: Acknowledgement (xserver-xfree86: When installing with a radeon 9200 SE (1002:5964) the ati wrapper doesn't recognize it, radeon is ok)

[Sven Luther]

On Wed, Dec 15, 2004 at 03:08:13PM -0500, Branden Robinson wrote:
> On Fri, Dec 10, 2004 at 01:43:45PM +0100, Sven Luther wrote:
> > On Fri, Dec 10, 2004 at 04:42:22AM -0500, Branden Robinson wrote:
> > > Do you have any suggestions for how this could be rectified?
> > 
> > Well, i am a bit lost here, but more to this below ...
> > 
> > > Does the PCI ID matching code fail to disregard secondary (i.e., non-zero)
> > > functions in the PCI ID?  *Should* it disregard secondary functions?
> > 
> > Well, i don't understand why the primary pci-id is not chosen here, but only
> > the secondary one. I have some feeling that the wrapper iterates or 
> > something
> > and choses the secondary pci id since it is the last one. Maybe i should
> > rebuild the driver and do some creative debugging to see what happens. See, 
> > if
> > you had accepted the driver-sdk patch all those years ago, i wouldn't need 
> > 4GB
> > and hours of compiling to make this happen :) To add to this, i only have 
> > the
> > prototype cpu module right now, which sometimes segfaults on heavy 
> > compilatin
> > :/
> > 
> > > Or is the fix simply to add the ID for the "(Secondary)" device to the ati
> > > driver, so it knows to load the radeon submodule?
> > 
> > Well, both fixes should do : 
> > 
> >   1) make the ati wrapper use only the primary function for identifying the
> >   card.
> > 
> >   2) add the secondary pci-id to the ati wrapper.
> > 
> > I don't know if the ati card work like the 3dlabs wildcat VP, where you can
> > configure the card into behaving as two fully independent heads (with two
> > framebuffers and two accel pipes and so on), then it makes sense to go for 
> > 2),
> > but i don't think this is the case, so i would guess 1) is the way to go, 
> > and
> > this is an upstream bug, maybe they even have a fix already for this, did 
> > you
> > check ? 
> 
> I'm not precisely sure where to look.  Keep in mind that Debian doesn't
> have a proper upstream for XFree86 anymore.  X.Org is a different, albeit

Well, in this case, the upstream would be the ati driver author, which means
the ati folk, which are upstream for X.org too.

> related codebase, and even if The XFree86 Project, Inc. didn't have
> something other than heaping mounds of scorn for Debian, I'm pretty sure
> they don't support 4.3.0 anymore.

Yep. But as said, the code in question is copyrighted by the ATI folk, and
they most assuredly care about that. If nothing else, you could ask Michel.

> > > I could use some advice as to what the best path forward is, even once I
> > > have more information from the submitter, so I am tagging this bug "help".
> > 
> > Ok. I would :
> > 
> >   1) contact radeon driver upstream to see if they have a newer version 
> > which
> >   fixes this.
> 
> It's not clear to me who owns the ATI driver at freedesktop.org.  Just
> within the past two months it's been hacked on by Roland Mainz, Vladimir
> Dergachev, Alex Deucher, Egbert Eich, Daniel Stone, Michel Dänzer, "kuhn",
> and Matthieu Herrb.

Well, i would ask Michel to be sure, but i was under the impression that most
of that code came from ATI in more or less direct way. I may be wrong though.

> All that activity is great in contrast to XFree86; unfortunately, it leaves
> me puzzled as to who has ownership of that part of the tree.  ;)

I think some of those are already X.org folk, and some are also DDs, so it
should not be so difficult to get the straigth out of it.

> >   2) make the ati wrapper use only the first function.
> > 
> > Investigating 2) right now, but i don't promise anything.
> 
> Any luck on this yet?

Not much, it is a huge function and i have been busy. I get some feeling that
it is in radeon_probe.c in the RADEONProbe function that things happen though.

Maybe we should look at it, and put some debug in it, and see if it gets
called two time. Maybe just adding the secondary pci id would be enough
though, not sure.

> > BTW, next time, please bcc control, so idon't need to remove it when 
> > replying :)
> 
> I'd rather not -- it serves as a means of documenting the top of the mail
> message to people who would otherwise have trouble figuring out what that
> stuff is.

Well, the message is the same, you just don't get the [EMAIL PROTECTED] when 
you do
a group reply.

Friendly,

Sven Luther

Bug#281050: xserver-common: [i810] Memory leak

[Branden Robinson]

On Sun, Dec 12, 2004 at 01:39:35AM +, Anders Karlsson wrote:
> > 1) Have you read the Debian X FAQ entry on this issue?
> > 
> >
> > http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml#xservmemory
> 
> I had not read that particular entry, but have read it now. I already
> knew how the X server worked though, about caching pixmaps etc.

Okay -- sorry for the redundancy.

> > 2) Do you think you are experiencing the same problem as seen in bug
> >#279940?
> > 
> >http://bugs.debian.org/279940
> 
> I am experimenting with that now, although my results will not be
> relevant to this case anymore, as I have migrated the problematic
> machine onto Ubuntu. If the "leak" I experience is in the flash plugin,
> I should still see the problem, even if I have ditched XFree86 in favour
> of X.org.
> 
> > 3) Can you please use the "xrestop" program and provide (text) screenshots
> >of its operation, so we can see if there are any culpable clients?
> 
> Uhm, as I said above, my results will probably not have any bearing on
> this defect anymore. If it looks like the flash problem, I will post
> snapshots of xrestop. It should be Firefox eating huge amounts of X
> memory but I would have thought that closing the browser should free
> that memory from the X server, or is that a wrong assumption...

You might try experimenting with the XAA pixmap options as I just suggested
in my mail to Gintautas Miliauskas; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284448 > for it.

-- 
G. Branden Robinson|  "To be is to do"   -- Plato
Debian GNU/Linux   |  "To do is to be"   -- Aristotle
[EMAIL PROTECTED] |  "Do be do be do"   -- Sinatra
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: DRI and multiple X servers

[Dan Christensen]

Tomas Nykung <[EMAIL PROTECTED]> writes:

> So, here is what I want:
> - 3 X servers running at the same time, started from kdm
> (for graphical login)
>
> - the first server running at 1024x768, with 16 bits colours, DRI enabled
> (for the kids, they mostly play games...)
>
> - the two others running at 1600x1200, with 24 bits colours
>
> So, I edited my /etc/kde2/kdm/Xservers file like this:
> :0 [EMAIL PROTECTED] /usr/X11R6/bin/X -dpi 75 -nolisten tcp vt7 -depth 16
> :1 [EMAIL PROTECTED] /usr/X11R6/bin/X :1 -dpi 100 -nolisten tcp vt8 -depth 24
> :2 [EMAIL PROTECTED] /usr/X11R6/bin/X :2 -dpi 100 -nolisten tcp vt9 -depth 24

> I understand that it's not possible to get DRI support for more than one
> X server at the same time (at least not yet).
> I expected the server running on :0 would be the one that would start
> first, and thus be the one with DRI support, but that doesn't seem to be
> the case... Instead it looks like this is more or less at random(?), and
> I cannot figure out how to tell X (or DRI?) which server that should get
> access to the DRI.

You can put 

   -xf86config XF86Config-4.dri

at the end of the :0 line and alter the config files so just this one
has DRI loaded.

I'd also like it if the order in which multiple X servers started
was more consistent.

Dan

Bug#253088: radeonfb corruption when killing X from outside X.

[Sven Luther]

On Wed, Dec 15, 2004 at 02:54:00PM -0500, Branden Robinson wrote:
> On Fri, Dec 10, 2004 at 10:38:16AM +0100, Sven Luther wrote:
> > On Fri, Dec 10, 2004 at 03:52:47AM -0500, Branden Robinson wrote:
> > > tag 253088 = help upstream moerinfo
> > > thanks
> > > 
> > > On Thu, Nov 11, 2004 at 12:41:35PM +0100, Sven Luther wrote:
> > > > I am seing this also, sortof, when i VT switch away from X, and then 
> > > > skill or
> > > > stop X in some way, the radeonfb text console is corrupted. When i 
> > > > restart X
> > > > blindly, then the console is ok again. When i kill X from inside X, 
> > > > then there
> > > > is no problem.
> > > 
> > > What exact video card are you using, according to the XFree86 log file?
> > 
> > $ lspci -s 01:08
> > 0001:01:08.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 
> > 9200] (rev 01)
> > 0001:01:08.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] 
> > (Secondary) (rev 01)
> > $ lspci -n -s 01:08
> > 0001:01:08.0 0300: 1002:5961 (rev 01)
> > 0001:01:08.1 0380: 1002:5941 (rev 01)
> > 
> > (II) Primary Device is: PCI 01:08:0
> > (--) Assigning device section with no busID to primary device
> > (WW) RADEON: No matching Device section for instance (BusID PCI:1:8:1) found
> > (--) Chipset ATI Radeon 9200 5961 (AGP) found
> 
> I'm not referring to that.  I'm referring to this sort of output:
> 
> (--) PCI: (0:13:0) Brooktree Corporation Bt878 Video Capture rev 2, Mem @ 
> 0xd780/12
> (--) PCI:*(1:0:0) ATI Technologies Inc unknown chipset (0x5961) rev 1, Mem @ 
> 0xe800/27, 0xd600/16, I/O @ 0xd800/8, BIOS @ 0xe7fe/17
> (--) PCI: (1:0:1) ATI Technologies Inc unknown chipset (0x5941) rev 1, Mem @ 
> 0xd800/27, 0xd580/16
> 
> (This is why I ask for complete logfiles.  Even an driver developer like
> yourself can't give me what I ask for.  :-/ )

Well, you said "What exact video card are you using, according to the XFree86
log file?", not "Send me the log please", so ...

Anyway, here it is attached ...

Notice that it contains mostly the exact same info that is found in the above
lspci output, namely the pci id :

(--) PCI:*(1:8:0) ATI Technologies Inc Radeon RV280 [Radeon 9200] rev 1, Mem @ 
0xc000/27, 0xc800/16, I/O @ 0x1000/8
(--) PCI: (1:8:1) ATI Technologies Inc unknown chipset (0x5941) rev 1, Mem @ 
0xd000/27, 0xc801/16

Notice how the unrecognized 0x5941 above is the same as the one from :
0001:01:08.1 0380: 1002:5941 (rev 01), and that lspci, and thus the kernel
knows that it is an : RV280 [Radeon 9200] (Secondary).

Friendly,

Sven Luther

This is a pre-release version of XFree86, and is not supported in any
way.  Bugs may be reported to XFree86@XFree86.Org and patches submitted
to [EMAIL PROTECTED]  Before reporting bugs in pre-release versions,
please check the latest version in the XFree86 CVS repository
(http://www.XFree86.Org/cvs).

XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-8 20040930073400 [EMAIL PROTECTED])
Release Date: 15 August 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.25-powerpc-smp ppc [ELF] 
Build Date: 30 September 2004
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
OS Kernel: Linux version 2.6.8-pegasos ([EMAIL PROTECTED]) (version gcc 3.3.5 
(Debian 1:3.3.5-2)) #1 Sun Dec 5 19:57:43 CET 2004 
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/XFree86.0.log", Time: Tue Dec 14 17:10:57 2004
(==) Using config file: "/etc/X11/XF86Config-4"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) |   |-->Monitor "Generic Monitor"
(**) |   |-->Device "ATI Technologies, Inc. RV280 [Radeon 9200 SE]"
(**) |-->Input Device "Generic Keyboard"
(**) Option "XkbRules" "xfree86"
(**) XKB: rules: "xfree86"
(**) Option "XkbModel" "pc104"
(**) XKB: model: "pc104"
(**) Option "XkbLayout" "us"
(**) XKB: layout: "us"
(==) Keyboard: CustomKeycode disabled
(**) |-->Input Device "Generic Mouse"
(WW) The directory "/usr/lib/X11/fonts/cyrillic" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/100dpi/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/75dpi/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/CID" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/Speedo" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/100dpi" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/75dpi" does not exist.
Entry deleted from font path.
(**) FontPath set to 
"unix/:7100,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/Type1"
(==) RgbPa

Bug#281050: xserver-common: [i810] Memory leak

[Branden Robinson]

On Sat, Dec 11, 2004 at 06:27:28PM +0200, Gintautas Miliauskas wrote:
> I have read the entry, but I don't think I have learned anything I don't
> know already.

Hmm, well, I guess the FAQ can't contain *all* knowledge.  :)

> > 2) Do you think you are experiencing the same problem as seen in bug
> >#279940?
> > 
> >http://bugs.debian.org/279940
> 
> Possibly; the symptoms are similar.  However, I'm sure it's not the
> flash plugin that is causing problems.  My friend also has this problem,
> and he found a way to reproduce it with gpdf (Gnome's PDF viewer).  Just
> use gpdf to open a largish PDF file (the IBM DB2 reference at
> ftp://ftp.software.ibm.com/ps/products/db2/info/vr82/pdf/en_US/db2s1e81.pdf
> having 900 pages worked well for me), and watch X memory usage soar.
> Closing gpdf afterwards does not help, however, opening the same file
> with gpdf again does not eat yet another 200MB of memory.

This smells very much like a resource leak to me.

> It could mean that some buffer is allocated by X and then enlarged as
> needed, but not shrunk later when it's not in use any more.

Sounds plausible.

> It's interesting to notice that memory is sucked further even when I'm
> browsing the already opened PDF file; I just held  for a few
> moments (the page counter went up to 297), waited for gpdf to stop CPU
> activity (I think it was rendering every page) and then I saw that X ate
> another 30MB.  xrestop also showed a several thousand increase in the
> 'Extra' column.

Yeesh.

> By the way, I'm not sure, but I think my friend said that he had an ATI
> video card.

If the leak is in the part of the server that it sounds like (DIX), it
should be completely hardware-neutral.

> I tried to reproduce this problem on several other machines (I don't
> know their hardware configurations, but I'm pretty sure the software is
> up to date, i.e., testing or unstable), but the problem did not manifest
> itself on those machines -- gpdf happily opened the files without any
> significant side effects.  I have little idea why the problem exists on
> my machine and on my friend's machine, but not on the others that I have
> tested.

Huh, well, damn.  I could be wrong about the problem being in the DIX
layer, then.

> > 3) Can you please use the "xrestop" program and provide (text)
> > screenshots of its operation, so we can see if there are any
> > culpable clients?
> 
> I am attaching snapshots of top, pmap and xrestop before starting gpdf
> (suffix ".before"), after opening the DB2 reference with gpdf (suffix
> ".after", and after closing gpdf (suffix ".closed").  My XF86Config-4
> and output of xdpyinfo are included as well.
> 
> Note that I wasn't using gpdf previously (nor was I opening large PDFs),
> so I don't think you should put all the blame on it as you did for the
> flash plugin.  I am experiencing a gradual increase of memory usage
> rather than sudden jumps.  There might be a bug in gpdf, but I am
> concerned with the fact that the memory is not released even after I
> quit gpdf.

I wonder if there is some stupid bug where some kind of backing store for
the pixmap cache is being established, but never recycled.  I don't really
know how this stuff works in detail, but I do know that XAA (X acceleration
architecture) let exposes the display adapter's 2D acceleration features to
the X server, and one of those features is use of parts of video memory as
a pixmap cache.  It seems to me that an implementor might want to keep a
shadow pixmap cache in main memory inside the X server, especially with the
crazy 3D hardware we have these days, which you sometimes have to reset
when they lock-up, which in turn (for all I know) could zero out or corrupt
the video RAM.  Of course, not all driver authors may want to have a shadow
cache in main memory, and/or a display adapter that didn't have 3D
acceleration features might not use them.

There's my crazy hypothesis for why this behavior might be seen only on
Radeon and i855 cards, but not others (they both have DRI drivers).
Hopefully if it's laughably off-base, some knowledgeable person will be
provoked into replying this message to set my delusional ass straight.

Anyway, one way to test at least parts of my hypothesis would be simply to
turn off the XAA pixmap cache.  To do this, add the following line to the
"Device" section of your XF86Config-4 file:

   Option "XaaNoPixmapCache"

It might be worth trying the following as well:

   Option "XaaNoOffscreenPixmaps"

Both of the above are documented in XF86Config-4(5x), by the way.

> I now tried opening several large apps (OpenOffice.org, GIMP, Eclipse,
> etc.) and some of the hogged-up memory was swapped out (resident block
> of X fell from 230MB to 107MB).  At least that stuff swaps out, but it
> still makes my system rather slow (perhaps because it starves the
> filesystem cache).

Possibly.

> Another very thing I have experienced a few times is an almost-complete
> freeze of my machine when exiting

Bug#284448: Got it. back traced core dump

[Branden Robinson]

On Sun, Dec 12, 2004 at 11:11:44PM +0100, David A. van Leeuwen wrote:
> OK, I got it.  After another upgrade to `testing' today, and a reboot 
> for a kernel parameter earlier today, My SiS6326 card started to crash 
> more consistently, even with the dfsg.1-4 package.  So I tried the 
> -dbg_4.3.0.dfsg.1-8 package under root and unlimited core size, and 
> after a while trying I caught the crash.
> 
> I hope Mozilla (in which I can't seem to include text from a file---i 
> must attach---sorry) shows the bug report properly.
> 
> I've noticed that a typical behaviour is: server either crashes on one 
> of the first 10-or-so launches of clients (doesn't matter which), or it 
> doesn't, and then tends to live very long.
> 
> I hope this information help you.

Hmm, well, given your backtrace, I might have been wrong about this being
SiS-specific.

See below.

> (gdb) bt
> #0  0x400f46b1 in kill () from /lib/libc.so.6
> #1  0x400f4435 in raise () from /lib/libc.so.6
> #2  0x400f5978 in abort () from /lib/libc.so.6
> #3  0x0847454c in ddxGiveUp () at xf86Init.c:1173
> #4  0x0847462b in AbortDDX () at xf86Init.c:1224
> #5  0x08516e5f in AbortServer () at utils.c:436
> #6  0x085187eb in FatalError (
> f=0x8a36fa0 "Caught signal %d.  Server aborting\n") at utils.c:1421
> #7  0x0848f646 in xf86SigHandler (signo=11) at xf86Events.c:1230
> #8  
> #9  0x40142a1f in memcpy () from /lib/libc.so.6
> #10 0x0892a025 in fs_read_list_info (fpe=0x8bcf350, blockrec=0x8d65198)
> at fserve.c:2376
> #11 0x089286fc in fs_read_reply (fpe=0x8bcf350, client=0x0) at fserve.c:1310
> #12 0x08928810 in fs_wakeup (fpe=0x8bcf350, mask=0x8b57f60) at fserve.c:1349
> #13 0x0850ae1d in FontWakeup (data=0x0, count=1, LastSelectMask=0x8b57f60)
> at dixfonts.c:190
> #14 0x084e759f in WakeupHandler (result=1, pReadmask=0x8b57f60)
> at dixutils.c:459
> #15 0x085107cb in WaitForSomething (pClientsReady=0xb8e4) at WaitFor.c:353
> #16 0x084de1dc in Dispatch () at dispatch.c:379
> #17 0x084f58c4 in main (argc=2, argv=0xbda4, envp=0xbdb0)
> at main.c:469
> (gdb) bt full -7
> #11 0x089286fc in fs_read_reply (fpe=0x8bcf350, client=0x0) at fserve.c:1310
>   conn = 0x8bcf378
>   blockrec = 0x8d65198
>   ret = 1
>   err = 85
>   rep = (fsGenericReply *) 0x8bcf808
> #12 0x08928810 in fs_wakeup (fpe=0x8bcf350, mask=0x8b57f60) at fserve.c:1349
>   LastSelectMask = (fd_set *) 0x8b57f60
>   conn = 0x8bcf378
> #13 0x0850ae1d in FontWakeup (data=0x0, count=1, LastSelectMask=0x8b57f60)
> at dixfonts.c:190
>   i = 0
>   fpe = 0x8bcf350
> #14 0x084e759f in WakeupHandler (result=1, pReadmask=0x8b57f60)
> at dixutils.c:459
>   i = 3
>   j = 1074663374
> #15 0x085107cb in WaitForSomething (pClientsReady=0xb8e4) at WaitFor.c:353
>   i = 1
>   waittime = {tv_sec = 30, tv_usec = 0}
>   wt = (struct timeval *) 0xb8b0
>   timeout = 599800
>   standbyTimeout = 1199800
>   suspendTimeout = 1799800
>   offTimeout = 2399800
>   clientsReadable = {fds_bits = {0 }}
>   clientsWritable = {fds_bits = {1, 34572, -1073743944, 137854978, 
> 148262064, 2048, -1073743912, 1, 146208600, 146208600, -1073743912, 
> 137858932, 148262296, 81928, 0, 1075039169, 146208600, 857, 0, 
> 1075818748, 0, 1075818728, 1075818732, -1073743888, 1075818656, 
> 1075818656, -1073743816, 1075039169, 1075818656, 0, 1053956, 1075818656}}
>   curclient = 16
>   selecterr = 0
>   nready = 1
>   devicesReadable = {fds_bits = {16, 0, 0, 0, 16, 148264696, 
> -1073744072, 139360755, 148264744, 148263348, 148263320, 146600824, 1, 
> 148261712, -1073743752, 139511553, 148264744, 139510958, 148262504, 
> -1073743792, -1073743892, -1073743796, 0, 148262232, 7, 56, 1075818656, 
> 1075815968, 1075818656, 1075818656, -1073743976, 1075035747}}
>   now = 43454
>   someReady = 0
> #16 0x084de1dc in Dispatch () at dispatch.c:379
>   clientReady = (int *) 0xb8e4
>   result = 0
>   client = 0x8d65728
>   nready = -1
>   icheck = (HWEventQueuePtr *) 0x8b55bc8
>   start_tick = 4440
> #17 0x084f58c4 in main (argc=2, argv=0xbda4, envp=0xbdb0)
> at main.c:469
>   i = 1
>   j = 2
>   k = 2
>   error = -1073742428
>   xauthfile = 0xbfb8 "/root/.Xauthority"
>   alwaysCheckForInput = {0, 1}
> (gdb) 

Can you show us the output of "bt full -9" instead, please?  I'm sorry if
my instructions were confusing; the goal is to get a close look at the
stack frames *right below* the point where the signal handler is called.
That can tell us, for example, if what we're dealing with is a good
old-fashioned null pointer dereference.

-- 
G. Branden Robinson|  Never underestimate the power of
Debian GNU/Linux   |  human stupidity.
[EMAIL PROTECTED] |  -- Robert Heinlein
http://people.debian.org/~branden/ |


signature.asc
Description: Digital sig

Bug#126519: personal loan number: 8312

[Emanuel Sellers]

You are permitted to get yourself a home loan online from one of the leading 
companies. 

It'll help increase your financial position:

http://quoteboss.com/?partid=yad

Bug#280738: Acknowledgement (xserver-xfree86: When installing with a radeon 9200 SE (1002:5964) the ati wrapper doesn't recognize it, radeon is ok)

[Branden Robinson]

On Fri, Dec 10, 2004 at 01:43:45PM +0100, Sven Luther wrote:
> On Fri, Dec 10, 2004 at 04:42:22AM -0500, Branden Robinson wrote:
> > Do you have any suggestions for how this could be rectified?
> 
> Well, i am a bit lost here, but more to this below ...
> 
> > Does the PCI ID matching code fail to disregard secondary (i.e., non-zero)
> > functions in the PCI ID?  *Should* it disregard secondary functions?
> 
> Well, i don't understand why the primary pci-id is not chosen here, but only
> the secondary one. I have some feeling that the wrapper iterates or something
> and choses the secondary pci id since it is the last one. Maybe i should
> rebuild the driver and do some creative debugging to see what happens. See, if
> you had accepted the driver-sdk patch all those years ago, i wouldn't need 4GB
> and hours of compiling to make this happen :) To add to this, i only have the
> prototype cpu module right now, which sometimes segfaults on heavy compilatin
> :/
> 
> > Or is the fix simply to add the ID for the "(Secondary)" device to the ati
> > driver, so it knows to load the radeon submodule?
> 
> Well, both fixes should do : 
> 
>   1) make the ati wrapper use only the primary function for identifying the
>   card.
> 
>   2) add the secondary pci-id to the ati wrapper.
> 
> I don't know if the ati card work like the 3dlabs wildcat VP, where you can
> configure the card into behaving as two fully independent heads (with two
> framebuffers and two accel pipes and so on), then it makes sense to go for 2),
> but i don't think this is the case, so i would guess 1) is the way to go, and
> this is an upstream bug, maybe they even have a fix already for this, did you
> check ? 

I'm not precisely sure where to look.  Keep in mind that Debian doesn't
have a proper upstream for XFree86 anymore.  X.Org is a different, albeit
related codebase, and even if The XFree86 Project, Inc. didn't have
something other than heaping mounds of scorn for Debian, I'm pretty sure
they don't support 4.3.0 anymore.

> > I could use some advice as to what the best path forward is, even once I
> > have more information from the submitter, so I am tagging this bug "help".
> 
> Ok. I would :
> 
>   1) contact radeon driver upstream to see if they have a newer version which
>   fixes this.

It's not clear to me who owns the ATI driver at freedesktop.org.  Just
within the past two months it's been hacked on by Roland Mainz, Vladimir
Dergachev, Alex Deucher, Egbert Eich, Daniel Stone, Michel Dänzer, "kuhn",
and Matthieu Herrb.

All that activity is great in contrast to XFree86; unfortunately, it leaves
me puzzled as to who has ownership of that part of the tree.  ;)

>   2) make the ati wrapper use only the first function.
> 
> Investigating 2) right now, but i don't promise anything.

Any luck on this yet?

> BTW, next time, please bcc control, so idon't need to remove it when replying 
> :)

I'd rather not -- it serves as a means of documenting the top of the mail
message to people who would otherwise have trouble figuring out what that
stuff is.

-- 
G. Branden Robinson|Any man who does not realize that
Debian GNU/Linux   |he is half an animal is only half a
[EMAIL PROTECTED] |man.
http://people.debian.org/~branden/ |-- Thornton Wilder


signature.asc
Description: Digital signature

Bug#261104:

[Herbert Valerio Riedel]

...just wondering whether there are any new informations about this bug?

Bug#253088: radeonfb corruption when killing X from outside X.

[Branden Robinson]

On Fri, Dec 10, 2004 at 10:38:16AM +0100, Sven Luther wrote:
> On Fri, Dec 10, 2004 at 03:52:47AM -0500, Branden Robinson wrote:
> > tag 253088 = help upstream moerinfo
> > thanks
> > 
> > On Thu, Nov 11, 2004 at 12:41:35PM +0100, Sven Luther wrote:
> > > I am seing this also, sortof, when i VT switch away from X, and then 
> > > skill or
> > > stop X in some way, the radeonfb text console is corrupted. When i 
> > > restart X
> > > blindly, then the console is ok again. When i kill X from inside X, then 
> > > there
> > > is no problem.
> > 
> > What exact video card are you using, according to the XFree86 log file?
> 
> $ lspci -s 01:08
> 0001:01:08.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 
> 9200] (rev 01)
> 0001:01:08.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] 
> (Secondary) (rev 01)
> $ lspci -n -s 01:08
> 0001:01:08.0 0300: 1002:5961 (rev 01)
> 0001:01:08.1 0380: 1002:5941 (rev 01)
> 
> (II) Primary Device is: PCI 01:08:0
> (--) Assigning device section with no busID to primary device
> (WW) RADEON: No matching Device section for instance (BusID PCI:1:8:1) found
> (--) Chipset ATI Radeon 9200 5961 (AGP) found

I'm not referring to that.  I'm referring to this sort of output:

(--) PCI: (0:13:0) Brooktree Corporation Bt878 Video Capture rev 2, Mem @ 
0xd780/12
(--) PCI:*(1:0:0) ATI Technologies Inc unknown chipset (0x5961) rev 1, Mem @ 
0xe800/27, 0xd600/16, I/O @ 0xd800/8, BIOS @ 0xe7fe/17
(--) PCI: (1:0:1) ATI Technologies Inc unknown chipset (0x5941) rev 1, Mem @ 
0xd800/27, 0xd580/16

(This is why I ask for complete logfiles.  Even an driver developer like
yourself can't give me what I ask for.  :-/ )

-- 
G. Branden Robinson| I suspect Linus wrote that in a
Debian GNU/Linux   | complicated way only to be able to
[EMAIL PROTECTED] | have that comment in there.
http://people.debian.org/~branden/ | -- Lars Wirzenius


signature.asc
Description: Digital signature

Bug#253607: Bug#243575: X configuration should allow to let out monitor frequencies and allow DDC to get them.

[Branden Robinson]

On Fri, Dec 10, 2004 at 10:35:26AM +0100, Sven Luther wrote:
> On Fri, Dec 10, 2004 at 04:01:46AM -0500, Branden Robinson wrote:
> > Apparently you haven't looked at the TODO on the debconf-overhaul branch
> > for several weeks:
> > 
> >   1928branden   + #253607: Accept blank values for monitor sync ranges, 
> > which will omit these
> >   1928branden parameters from the config file, relying upon the X 
> > server's DDC routines to
> >   1928branden figure them out.  Add warning to template that 
> > results might be suboptimal
> >   1928branden if this is done (XFree86 falls back to *very* 
> > conservative timings if DDC
> >   1928branden probing fails).
> > 
> > So, essentially, you don't have to waste any more time trying to persuade
> > me.  :)
> 
> Cool, but i suppose this is too late for sarge, right ? 

Not necessarily.  The question is, can I get enough testers for the
debconf-overhaul branch for us to be confident in it in time for sarge?

That remains to be seen.

-- 
G. Branden Robinson| One doesn't have a sense of humor.
Debian GNU/Linux   | It has you.
[EMAIL PROTECTED] | -- Larry Gelbart
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#280457: xterm: Save terminal data when X connection is lost

[Branden Robinson]

On Fri, Dec 10, 2004 at 10:40:50AM +0100, Vincent Lefevre wrote:
> On 2004-12-10 03:45:11 -0500, Branden Robinson wrote:
> > >   Severity: wishlist
> > 
> > I agree.  :)
> 
> Well, I considered that losing data (as long as the program has the
> control of them) was a bug.

No more of a bug than the Linux VCs losing the contents of their
scrollback buffers when the machine is powered off.

Output streams from character devices are not the same sort of "data" for
the purpose of bug severities as the contents of a filesystem.

My opinion, anyway.  You can feel free to start an argument about this on
-devel, or appeal my decision to the Technical Committee.  Except they punt
on most BTS wars, so you may just have to live with my decision.  ;-)

> The (only?) big problem with screen is that one cannot scrollback with
> the mouse.

If screen is linked against ncurses, it may be a "simple mattter of
programming" to enable sensitivity to mouse actions for it, similarly to
lynx.

> > Except for a vastly annoying problem having to do with the failure of
> > screen and xterm to cooperate regarding what the primary selection is,
> > I highly recommend it.
> 
> Hasn't this primary selection problem just been fixed as a consequence
> of the fix for bug 277832?

I'm not convinced yet that it has been fixed to my personal satisfaction.

(That said, I'm a real nitpicky bastard when it comes to the primary
selection, and I may end up just have to eat what Thomas Dickey feeds me.
:) )

-- 
G. Branden Robinson|The errors of great men are
Debian GNU/Linux   |venerable because they are more
[EMAIL PROTECTED] |fruitful than the truths of little
http://people.debian.org/~branden/ |men. -- Friedrich Nietzsche


signature.asc
Description: Digital signature

Bug#285818: xserver-xfree86: Display corruption for i855GM with external monitor

[Simon Guest]

Package: xserver-xfree86
Version: 4.3.0.dfsg.1-9
Severity: normal

When driving an external monitor (e.g. beamer) from my i855GM equipped
laptop, I get the top 80 or so lines of the display being garbage.
The display is also shifted vertically by this amount.  Since the mouse
position detection is not shifted, clicking on a button is rather
difficult, since things are not where they seem.

Basically, an external monitor is not usable with the i855GM.

However, there is a solution.  Andrea Merello's excellent i855crt user space
driver, available here:
http://sourceforge.net/projects/i855crt

It would be really nice if this could be integrated into the Debian X
server.  At least, the patch for the hardware cursor needs to be
integrated.

cheers,
Simon

-- Package-specific info:
Contents of /var/lib/xfree86/X.roster:
xserver-xfree86

/etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum.

X server symlink status:
lrwxrwxrwx  1 root root 20 2004-08-29 20:10 /etc/X11/X -> /usr/bin/X11/XFree86
-rwxr-xr-x  1 root root 1745740 2004-12-09 17:03 /usr/bin/X11/XFree86

Contents of /var/lib/xfree86/XF86Config-4.roster:
xserver-xfree86

VGA-compatible devices on PCI bus:
:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated 
Graphics Device (rev 02)

/etc/X11/XF86Config-4 does not match checksum in 
/var/lib/xfree86/XF86Config-4.md5sum.

XFree86 X server configuration file status:
-rw-r--r--  1 root root 3513 2004-08-29 21:18 /etc/X11/XF86Config-4

Contents of /etc/X11/XF86Config-4:
# XF86Config-4 (XFree86 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 XF86Config-4 manual page.
# (Type "man XF86Config-4" at the shell prompt.)
#
# This file is automatically updated on xserver-xfree86 package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xfree86
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following commands as root:
#
#   cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom
#   md5sum /etc/X11/XF86Config-4 > /var/lib/xfree86/XF86Config-4.md5sum
#   dpkg-reconfigure xserver-xfree86
Section "Files"
FontPath"unix/:7100"# local font server
# if the local font server has problems, we can fall back on these
FontPath"/usr/lib/X11/fonts/misc"
FontPath"/usr/lib/X11/fonts/cyrillic"
FontPath"/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath"/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath"/usr/lib/X11/fonts/Type1"
FontPath"/usr/lib/X11/fonts/CID"
FontPath"/usr/lib/X11/fonts/Speedo"
FontPath"/usr/lib/X11/fonts/100dpi"
FontPath"/usr/lib/X11/fonts/75dpi"
EndSection
Section "Module"
Load"GLcore"
Load"bitmap"
Load"dbe"
Load"ddc"
Load"dri"
Load"extmod"
Load"freetype"
Load"glx"
Load"int10"
Load"record"
Load"speedo"
Load"type1"
Load"vbe"
Load"synaptics"
EndSection
Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "keyboard"
Option  "CoreKeyboard"
Option  "XkbRules"  "xfree86"
Option  "XkbModel"  "pc105"
Option  "XkbLayout" "gb"
EndSection
Section "InputDevice"
Identifier  "Generic Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/input/mice"
Option  "Protocol"  "ImPS/2"
Option  "Emulate3Buttons"   "true"
Option  "ZAxisMapping"  "4 5"
EndSection
Section "InputDevice"
Driver  "synaptics"
Identifier  "Synaptics TouchPad"
Option  "Device""/dev/psaux"
Option  "Protocol"  "auto-dev"
Option  "LeftEdge"  "1700"
Option  "RightEdge" "5300"
Option  "TopEdge"   "1700"
Option  "BottomEdge""4200"
Option  "FingerLow" "25"
Option  "FingerHigh""30"
Option  "MaxTapTime""180"
Option  "MaxTapMove""220"
Option  "VertScrollDelta" "100"
Option  "MinSpeed"  "0.06"
Option  "MaxSpeed"  "0.12"
Option  "AccelFactor" "0.0010"
Option  "SHMConfig" "on"
#   Option  "Repeater"  "/dev/ps2mouse"
EndSection
Section "Device"
Identifier  "Generic Video Card"
Driver  "i810"
EndSection
Section "Monitor"
Identifier  "Color LCD"
HorizSync   30-60
VertRefresh 50-75
Option  "DPMS"
EndSection

Bug#284448: xserver-xfree86: xserver (ATI or Radeon something 7500) crashes on variouslaunches of programcs from within X.

[Branden Robinson]

retitle 284448 xserver-xfree86: [sis] SEGV in memcpy() called from 
fs_read_list_info() on 86C326 5598/6326 rev 210
tag 284448 + upstream
thanks

On Wed, Dec 08, 2004 at 11:09:22PM +0100, David A. van Leeuwen wrote:
> Branden Robinson wrote:
> 
> >If the justification is "unknown", it might as well not be present.
> >
> Sorry, this is my first bug report (after using debian for many years, 
> since 0.7 or so), and I believe the script suggested that.

Hmm, okay.  Well, this might be a difference of opinion between me and the
person who wrote that, so let's not worry about it for now.  :)

> >This bug is not a report of a Policy violation, nor does failure of the
> >X server to work on a particular piece of video hardware -- notably one
> >which you haven't actually identified -- constitute a bug which renders
> >the package "unsuitable" for release.
> > 
> >
> unsuitable it is, therefore.  But since today it has become worse.  My 
> computer at home, with---from lspci:
> :01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 
> 86C326 5598/6326 (rev d2)
> ---graphics card now shows the same behaviour. 
> 
> X-Server crashes on rxvt launch from gnome panel.  Happened several 
> times now.  I had a xserver-xfree86-3.1.0.dfsg.1-4 .deb left around, I 
> am using that now, hoping it won't die on my while composing the message...

Apparently it didn't.

> >A crashing bug that affected all users of xserver-xfree86 would be a 
> >different
> >story.
> >
> Well, so first there was the ati/radeon 7500 and now the SiS 6326. 

We have been updating both the ati/radeon and sis drivers during the
4.3.0-* period.

There could be distinct issues with each driver, and you're unlucky enough
to see both of them.

Believe me, if the X server were completely busted for everyone, I'd know
it.

> I believe I am not using 3D, not using DRI in the case of the ati/radeon 
> 7500 (I commented the module out at some stage without positive effect).

Okay.

I think we're looking at separate defects here.  I'm going to repurpose this
bug to focus solely on the SiS issue.

-- 
G. Branden Robinson|It's extremely difficult to govern
Debian GNU/Linux   |when you control all three branches
[EMAIL PROTECTED] |of government.
http://people.debian.org/~branden/ |-- John Feehery


signature.asc
Description: Digital signature

Processed: Re: Bug#284448: xserver-xfree86: xserver (ATI or Radeon something 7500) crashes on variouslaunches of programcs from within X.

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 284448 xserver-xfree86: [sis] SEGV in memcpy() called from 
> fs_read_list_info() on 86C326 5598/6326 rev 210
Bug#284448: xserver-xfree86: [ati/radeon] server crashes while doing 
unspecified activity on Radeon 'something' 7500
Changed Bug title.

> tag 284448 + upstream
Bug#284448: xserver-xfree86: [sis] SEGV in memcpy() called from 
fs_read_list_info() on 86C326 5598/6326 rev 210
Tags were: upstream moreinfo
Tags added: upstream

> thanks
Stopping processing here.

Please contact me if you need assistance.

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

Re: libxv1 breaks apt-get and so my Debian.

[Branden Robinson]

On Thu, Dec 09, 2004 at 01:22:51PM +0100, Uwe Brauer wrote:
> Hi
> 
> Some 14 days ago I sent a bug report about that issue.
> It is really urgent since I cannot install nor upgrade nor anything
> right now on the system.
> 
> Here come the bug report again, I really would appreciate any help.

1) Sending the same bug report again and again is not a good way to
persuade volunteers to help you;

2) You're in violating of the Debian Mailing List Code of Conduct.  See
below.

[The following is a form letter.]

Hello,

You recently sent a message to a Debian Project mailing list to which I am
subscribed, and also included me in the To or CC header.

Please don't do this.  The Debian Mailing List Code of Conduct says:

  When using the Debian mailing lists, please follow these rules:

[...]
  * When replying to messages on the mailing list, do not send a carbon
copy (CC) to the original poster unless they explicitly request to be
copied.

(You can review the entire Debian Mailing List Code of Conduct at
http://www.debian.org/MailingLists/>.)

Rationally interpreted, this of course includes anything that works
equivalently to a CC, such including the original poster in the To: or Bcc:
headers, forwarding the message to the original poster, or using the
"bounce" feature of some mailers to send the message again, but rewriting the
SMTP envelope to address the original poster instead of the list.

Some people feel that it is best to send email to everyone who might
possibly be interested in a message, indifferent to whom might be
subscribed to various mailing lists, be part of the expansion of various
mailing lists, be behind an SMTP exploder, and so forth -- in other words,
that it is the responsibility of the recipient of duplicate mail messages
to handle them.

The Debian Mailing List Code of Conduct does not endorse that philosophy.
There are proven limitations with using procmail rules to eliminate
duplicate message based on Message-ID, for instance.  More importantly, the
Debian Mailing List Code of Conduct expects the *senders* of mail to
exercise discretion and good judgement; it does not place the burden of
pruning unwanted copies of mail messages upon the recipient.  You can find
discussions of this aspect of the Mailing List Code of Conduct in the
Debian mailing lists themselves, if you are interested: please see
http://lists.debian.org/search.html> to perform a search.

The subject has come up several times over the past years, and time and
again, the existing policy has been affirmed as the wisest course of
action.  Many people, myself included, use the Mail-Followup-To and
Mail-Copies-To message headers, which are honored by mail user agents such
as Mutt to control the distribution of replies to mailing lists.   Using
such headers, a person can easily indicate that he does (or does not) want
to be sent copies of replies to his message.  You may want to use an MUA
that honors these headers, as they are in fairly wide usage on the Debian
mailing lists, and may help you avoid mistakes resulting in inadvertent
violations of Debian's Mailing List Code of Conduct.

You can read more about the Mail-Followup-To and Mail-Copies-To message
headers at:

http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-to-00.txt
http://www.newsreaders.com/misc/mail-copies-to.html

Please note that no assertions of deliberate misconduct on your part are
intended by this message.  It is meant only to advise you as to how to
communicate more harmoniously with people involved with the Debian Project.

Thank you for your patience with this form letter, for your respect for the
Debian Project's mailing list conventions, and for your participation in
Debian.

-- 
G. Branden Robinson|   If you want your name spelled
Debian GNU/Linux   |   wrong, die.
[EMAIL PROTECTED] |   -- Al Blanchard
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Processed: Re: Bug#275492: xserver-xfree86: [debconf] suboptimal driver suggested for Intel Corp. 82852/855GM Integrated Graphics Device rev 2

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 275492 discover-data: suboptimal driver suggested for Intel Corp.  
> 82852/855GM Integrated Graphics Device rev 2 (8086:3582 suggests vesa, should 
> be i810)
Bug#275492: xserver-xfree86: [debconf] suboptimal driver suggested for Intel 
Corp. 82852/855GM Integrated Graphics Device rev 2
Changed Bug title.

> reassign 275492 discover-data
Bug#275492: discover-data: suboptimal driver suggested for Intel Corp.  
82852/855GM Integrated Graphics Device rev 2 (8086:3582 suggests vesa, should 
be i810)
Bug reassigned from package `xserver-xfree86' to `discover-data'.

> clone 275492 -1
Bug#275492: discover-data: suboptimal driver suggested for Intel Corp.  
82852/855GM Integrated Graphics Device rev 2 (8086:3582 suggests vesa, should 
be i810)
Bug 275492 cloned as bug 285817.

> retitle -1 discover1-data: suboptimal driver suggested for Intel Corp.  
> 82852/855GM Integrated Graphics Device rev 2 (8086:3582 suggests vesa, should 
> be i810)
Bug#285817: discover-data: suboptimal driver suggested for Intel Corp.  
82852/855GM Integrated Graphics Device rev 2 (8086:3582 suggests vesa, should 
be i810)
Changed Bug title.

> reassign -1 discover1-data
Bug#285817: discover1-data: suboptimal driver suggested for Intel Corp.  
82852/855GM Integrated Graphics Device rev 2 (8086:3582 suggests vesa, should 
be i810)
Bug reassigned from package `discover-data' to `discover1-data'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

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

Bug#285807: MiscPassMessage() broken

[Thomas Winischhofer]

Package: xserver-xfree86
Version: 4.3.0.dfsg.1-9


Branden,
Fabio,

In June 2004, you added a patch to the Debian SVN that added the 
MiscPassMessage() mechanism for the misc extension[0].


As it turned out yesterday during my attempts of actually using this 
mechanism, it is entirely broken due to


1) a severe bug in the handling of the message value string (the message 
value was copied from an invalid memory location), and


2) two severe memory leaks.

I have committed patches to fix this to the XFree86 CVS today (Dec 15), 
changing two files:


- xc/programs/Xserver/Xext/xf86misc.c
- xc/include/extensions/xf86mscstr.h

The first file was subject to three commits on Dec 15 [1] (2 by me, one 
by Marc Aurele De France fixing a small bug in my first patch)


I am sorry for not being able to provide you with patches relative to 
Debian's current versions of these files (my HD already carries 8 
complete source trees of XFree86 and X.org).


Anyhow, I encourage you to grab these patches from XFree86 CVS in order 
to complete the mission originally intended.


My changes are NOT covered by the XFree86 license 1.1 but the old 
license, which is GPL compatible as we all know. The very same patches 
went into X.org CVS as of today as well.



Thomas


[0] : http://lists.debian.org/debian-x/2004/06/msg00629.html
[1] : http://www.mail-archive.com/cvs-commit@xfree86.org/msg04005.html
  http://www.mail-archive.com/cvs-commit@xfree86.org/msg04006.html
  and two following (not yet in mail archive as of this writing)


--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org

X Strike Force XFree86 SVN commit: r2075 - branches/4.3.0/sid/debian

[X Strike Force SVN Repository Admin]

Author: fabbione
Date: 2004-12-15 12:41:43 -0500 (Wed, 15 Dec 2004)
New Revision: 2075

Modified:
   branches/4.3.0/sid/debian/changelog
Log:
Set uploader field in preparation for 4.3.0.dfsg.1-10 release.


Modified: branches/4.3.0/sid/debian/changelog
===
--- branches/4.3.0/sid/debian/changelog 2004-12-15 17:39:31 UTC (rev 2074)
+++ branches/4.3.0/sid/debian/changelog 2004-12-15 17:41:43 UTC (rev 2075)
@@ -39,7 +39,7 @@
 
   * Fix syntax error in xdm's Xstartup script.  (Closes: #285150)
 
- -- Branden Robinson <[EMAIL PROTECTED]>  Sun, 12 Dec 2004 15:39:46 -0500
+ -- Fabio M. Di Nitto <[EMAIL PROTECTED]>  Wed, 15 Dec 2004 18:40:17 +0100
 
 xfree86 (4.3.0.dfsg.1-9) unstable; urgency=high
 

X Strike Force XFree86 SVN commit: r2074 - in branches/4.3.0/sid/debian: . local local/xdm patches

[X Strike Force SVN Repository Admin]

Author: fabbione
Date: 2004-12-15 12:39:31 -0500 (Wed, 15 Dec 2004)
New Revision: 2074

Added:
   branches/4.3.0/sid/debian/patches/099m_mga_increase_minimum_pixel_clock.diff
   branches/4.3.0/sid/debian/patches/099n_fbdev_driver_message_improvements.diff
Modified:
   branches/4.3.0/sid/debian/CHANGESETS
   branches/4.3.0/sid/debian/TODO
   branches/4.3.0/sid/debian/changelog
   branches/4.3.0/sid/debian/local/FAQ.xhtml
   branches/4.3.0/sid/debian/local/xdm/Xstartup
   branches/4.3.0/sid/debian/xfs.init
Log:
Merge revisions 2053:HEAD from trunk in preparation for 4.3.0.dfsg.1-10
release.



Modified: branches/4.3.0/sid/debian/CHANGESETS
===
--- branches/4.3.0/sid/debian/CHANGESETS2004-12-14 08:48:07 UTC (rev 
2073)
+++ branches/4.3.0/sid/debian/CHANGESETS2004-12-15 17:39:31 UTC (rev 
2074)
@@ -9,357 +9,50 @@
 files anywhere.)
 
 Miscellaneous cosmetic fixes.
-1915, 1916, 1919, 1920, 1932, 1934, 1940, 1951, 1960, 2008, 2014, 2015,
-2016, 2020, 2021, 2022, 2028, 2030, 2047
+2059, 2062
 
-Update Danish debconf template translations (thanks, Claus Hindsgaul).
-(Closes: #274101)
-1905
+Make factual updates, clarifications, and wording corrections to the FAQ:
++ Point out that the X.Org relicensing debacle was back in 1998, not
+  recent.
++ Be more clear about why OS distributors stuck with XFree86 after it was
+  forked, but before it was relicensed.
++ Identify which license is referred to as the "XFree86 1.1 license".
++ Clarify the origin of the contradictory statements regarding the
+  GPL-compatibility of XFree86.
++ Clarify the discussion of the "relicensing pilot project" that was
+  performed on the XFree86 "auto-config" code.  The code was checked in,
+  *then* relicensed without other changes.
++ Point out that most distributors have settled on X.Org's X11R6.8.1 for
+  their X Window System implementation, at least for the time being.
++ Stress that XFree86 3.x is no longer supported.
++ Remove language that discusses future directions of XFree86 3.x support
+  in dexconf, since it is unlikely that that work is going to happen.
+2054
 
-Edit xc/programs/xkbcomp/symbols/pc/Imakefile so that the new pc/us_intl
-layout file gets installed.  Update MANIFEST files and xlibs.install to
-ensure the file get shipped.
-+ Ship a multi-layout aware us_intl layout.  (Closes: #271326)
-+ Make us_intl work again.  (Closes: #274513)
-1906, 1907, 1911, 1912, 1923
+Increase the minimum pixel clock for Matrox cards based on feedback from
+Teemu Ikonen.  (Closes: #261993)
+2055, 2056
 
-Add FAQ entry: Why does composing characters work in some applications but
-not others?
-1908, 1913
+Tidy up and improve fbdev driver messages, correcting spelling, adding
+information, and otherwise enhancing them.  (Closes: #275318)
+2058
 
-Make Sun keyboards load srvr_ctrl(xfree86) symbol definitions to have
-access to standard Ctrl+Alt key sequences.  (Closes: #236086)
-1914, 1942
+Make corrections to the "How does the keyboard work in the X Window
+System?" FAQ entry based on feedback from Frank Murphy.  Thanks, Frank!
+(Closes: #279055)
+2068
 
-Apply patch from Jan Wilhelm Stumpel to correct miscoded Unicode Plane 1
-characters in en_US.UTF-8 compose map.  (Closes: #267321)
-1917
+Expand discussion of configuring the mouse for left-handed use in the FAQ.
+Thanks to Marc-Aurèle DARCHE for the information!  (Closes: #281504)
+2069
 
-Update wacom driver from http://linuxwacom.sourceforge.net/ up to 0.6.4.
-+ Remove now obsolete patch 036_wacom_usb_tablet_update.diff
-+ Add patch 000_stolen_from_sourceforge_wacom_driver.diff
-+ Fix input timeout problems if the device is not connected.
-  No references are available in upstream changelog, but tests do not
-  show this behavior anymore. (Closes: #231837)
-+ Fix compatibility with kernel 2.6 wacom driver. (Closes: #250331)
-+ Add support for Cintiq boards. According to #172526 logs the patch
-  has been included, reworked and cleaned by upstream a long time ago.
-  No references are available in upstream changelog. (Closes: #172526)
-+ A combination of new kernel, xfree86 and wacom driver appears to have
-  fixed the APM resume issue as described in #80140. Tests done
-  on a powerpc laptop do not show this problem anymore.
-  No references are available in upstream changelog. (Closes: #80140)
-1921, 1924
+Fix syntax error in xfs package's init script.  (Closes: #285133)
+2070
 
-Install xlibs's bug script in the binary-indep rule, not binary-arch,
-since xlibs is an architecture "all" package.  Now the script will
-actually be shipped.
-1922
+Fix syntax error in xdm's Xstartup script.  (Closes: #285150)
+2071
 
-Add workaround for the UseBIOS default setting in the savage driver:
-+ Add patch 099i_pro_savage_ddr_set_use_bios_to_false.diff
-+ Set UseBios default to "no" for PROSAVAGE_DDR and PROSAVAGE_DDRK, as
-  described at http://www.

Bug#116507: Just one hit.

[Preston Kenny]

You might think that running to the doctor is the answer.

Well oftentimes its a little easier to go to a website and get the same 
solution.

Especially when it comes to those aches and pains.

You might even think that giving you that type of pain is easy?
 
It isn't! Your pain works hard!
 
So go here http://www.ncy193.dbzwishdfef.com to arrange an extended vacation 
for your pain.

(Just so you should know, this is absolutely the best pharmacy online 
guaranteed)

And I've seen a couple :-)

Preston Kenny

PS. 4 Free C1aL1s with every single order!

No Thank you I do not want my free C1aL1s and in addition I will stick with my 
pains and aches.
http://www.spjq.dbzwishdfef.com/bye/ 

Bug#285782: xdm fails to login due to error in Xstartup

[Martin Stolle]

Package: xdm
Version: 4.3.0.dfsg.1-9
Severity: grave
Justification: renders package unusable


The last version of xdm tries to "clean-up" Xstartup, but messes up the
xsessreg  invocation by removing a \  continuation at the end of the
line.  As a result, Xstartup dies and noone can log on. bad.

MST


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages xdm depends on:
ii  cpp   4:3.3.5-1  The GNU C preprocessor (cpp)
ii  debconf [debconf-2.0] 1.4.41 Debian configuration management sy
ii  libc6 2.3.2.ds1-19   GNU C Library: Shared libraries an
ii  libice6   4.3.0.dfsg.1-9 Inter-Client Exchange library
ii  libpam-modules0.76-22Pluggable Authentication Modules f
ii  libpam-runtime0.76-22Runtime support for the PAM librar
ii  libpam0g  0.76-22Pluggable Authentication Modules l
ii  libsm64.3.0.dfsg.1-9 X Window System Session Management
ii  libxaw7   4.3.0.dfsg.1-9 X Athena widget set library
ii  libxext6  4.3.0.dfsg.1-9 X Window System miscellaneous exte
ii  libxmu6   4.3.0.dfsg.1-9 X Window System miscellaneous util
ii  libxpm4   4.3.0.dfsg.1-9 X pixmap library
ii  libxt64.3.0.dfsg.1-9 X Toolkit Intrinsics
ii  xbase-clients 4.3.0.dfsg.1-9 miscellaneous X clients
ii  xlibs 4.3.0.dfsg.1-9 X Keyboard Extension (XKB) configu

-- debconf information:
* shared/default-x-display-manager: xdm
  xdm/stop_running_server_with_children: false
  xdm/daemon_name: /usr/bin/X11/xdm

Processed: reassign 281050 to xserver-xfree86

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.8.5
> reassign 281050 xserver-xfree86
Bug#281050: xserver-xfree86: server has memory leaks
Warning: Unknown package 'server'
Warning: Unknown package 'has'
Warning: Unknown package 'memory'
Warning: Unknown package 'leaks'
Bug reassigned from package `xserver-xfree86: server has memory leaks' to 
`xserver-xfree86'.

>
End of message, stopping processing here.

Please contact me if you need assistance.

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

Processed: tagging 279055

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.8.5
> tags 279055 - moreinfo
Bug#279055: xfree86-common: Keyboard configuration FAQ has some typos and is 
not always clear enough
Tags were: pending moreinfo
Tags removed: moreinfo

>
End of message, stopping processing here.

Please contact me if you need assistance.

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

Processed: tagging 253088

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.8.5
> tags 253088 = help upstream moreinfo
Bug#253088: xserver-xfree86: [ati/radeon] VT switching corrupts text consoles 
on Radeon RV280 [Radeon 9200] rev 1
Tags were: upstream help
Tags set to: help, upstream, moreinfo

>
End of message, stopping processing here.

Please contact me if you need assistance.

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

DRI and multiple X servers

[Tomas Nykung]

Please allow an long time lurker on this list to ask one question, even
if it might be slightly OT here, ok? :)

I'm still running Debian Woody, but with several backported packages
to get support for my hardware, among others, I've installed Norbert's
backport of X, version 4.3.0.dfsg.1-7.woody.1, to get support for my
(cheap) Radeon 9200 SE graphics card that I've recently bought.
(This works well, at least for me, thanks Norbert if you happens to read
this!)

I of course understand that this is unsupported, my install isn't
anywhere near a standard Debian install and what I want to do isn't
standard either :)



So, here is what I want:
- 3 X servers running at the same time, started from kdm
(for graphical login)

- the first server running at 1024x768, with 16 bits colours, DRI enabled
(for the kids, they mostly play games...)

- the two others running at 1600x1200, with 24 bits colours

So, I edited my /etc/kde2/kdm/Xservers file like this:
:0 [EMAIL PROTECTED] /usr/X11R6/bin/X -dpi 75 -nolisten tcp vt7 -depth 16
:1 [EMAIL PROTECTED] /usr/X11R6/bin/X :1 -dpi 100 -nolisten tcp vt8 -depth 24
:2 [EMAIL PROTECTED] /usr/X11R6/bin/X :2 -dpi 100 -nolisten tcp vt9 -depth 24

and the relevant part of my XF86Config-4 file looks like this:
SubSection "Display"
Depth   16
Modes   "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth   24
Modes   "1600x1200" "1024x768" "800x600" "640x480"
EndSubSection


This gives me what I wanted:
3 kdm logins, first one on vt7, running 1024x768 16 bits, and the two
others on vt8 and vt9, running 1600x1200 24 bits.

The problem is just with the 3D support...
I understand that it's not possible to get DRI support for more than one
X server at the same time (at least not yet).
I expected the server running on :0 would be the one that would start
first, and thus be the one with DRI support, but that doesn't seem to be
the case... Instead it looks like this is more or less at random(?), and
I cannot figure out how to tell X (or DRI?) which server that should get
access to the DRI.

So, my question is, Is it possible somehow to determine which X server
should have access to the DRI functions?

Of course I could start just the first X server with kdm, and then start
the others with startx -- :1 ... and so on.
Then the first server would always be the one with DRI support as I
want it to be. This would be a good enough solution for me, but it isn't
exactly the most user friendly solution for the other persons using the
same computer.


Any hints from the X and DRI experts on the list?



Tomas

Bug#282035: xserver-xfree86: [kbd] Logitech "Internet Navigator Special Edition" / "Elite" USB Keyboard missing 4 buttons

[Chris Boyle]

On Wed, Dec 15, 2004 at 07:54:08AM +0100, Denis Barbier wrote:
> Yes, but your mouse wheel should be taken into account.
> About these 4 keys, I do not know how this can be fixed.

...ah ha. This is meant for PS/2 mode, isn't it? I will try it again
when I find the required adaptor, but I'm using USB mode, in which the
wheel actually shows up in a completely separate USB device, a mouse
(N.B. not the actual mouse I have, but a fake one generated by the
keyboard). I think earlier, bizarrely, I found these missing buttons
appearing in that device too.

...perhaps this is a kernel bug? Or is my hardware really so completely
mis-designed?

-- 
Chris Boyle - http://cmb.is-a-geek.org/
GPG: B7D86E0F, MSN: [EMAIL PROTECTED], ICQ: 24151961,
AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on irc.uwcs.co.uk

Bug#282035: xserver-xfree86: [kbd] Logitech "Internet Navigator Special Edition" / "Elite" USB Keyboard missing 4 buttons

[Denis Barbier]

On Tue, Dec 14, 2004 at 11:51:22PM +, Chris Boyle wrote:
> On Wed, Dec 15, 2004 at 12:38:59AM +0100, Denis Barbier wrote:
> > XKeyboard-Config from freedesktop.org has a new entry which seems
> > to match your keyboard, can you please test it?
> > This patch can be applied against /etc/X11/xkb.
> 
> Same as before I'm afraid. /var/log/XFree86.0.log confirms the new model
> is in effect, but those 4 keys show nothing in xev, and only two of the
> function keys (F-Lock off) show up, as the wrong thing.

Yes, but your mouse wheel should be taken into account.
About these 4 keys, I do not know how this can be fixed.

Denis