Bug#425814: xserver-xorg-video-ati: Xv broken on Mach64 3D Rage LT Pro AGP-133
On Fri, 2007-05-25 at 08:44 +0200, Michel Dänzer wrote: > On Thu, 2007-05-24 at 22:15 +0200, Svante Signell wrote: > > On Thu, 2007-05-24 at 20:54 +0200, Svante Signell wrote: > > > On Thu, 2007-05-24 at 11:44 +0200, Brice Goglin wrote: ... > > I have now downgraded the following packages: > > apt-get install xserver-xorg-core=2:1.1.1-21 xserver-xorg=1:7.1.0-16 > > apt-get install xserver-xorg-video-ati (1:6.6.3-2 from Stable) > > With them all works OK! > > What about the new version of xserver-xorg-core with the old version of > xserver-xorg-video-ati? This was the original setup since version 1:6.6.3-2 is used by both stable and unstable. The problem seems to be in one of the downgraded packages! It seems I can upgrade xserver-xorg-core to 2:1.3.0.0.dfsg-5 without upgrading xserver-xorg to 1:7.2-3 but do you really think the problem is in xserver-xorg-7.2?
Bug#425814: xserver-xorg-video-ati: Xv broken on Mach64 3D Rage LT Pro AGP-133
On Fri, 2007-05-25 at 09:17 +0200, Svante Signell wrote:
> On Fri, 2007-05-25 at 08:44 +0200, Michel Dänzer wrote:
> > On Thu, 2007-05-24 at 22:15 +0200, Svante Signell wrote:
> > > On Thu, 2007-05-24 at 20:54 +0200, Svante Signell wrote:
> > > > On Thu, 2007-05-24 at 11:44 +0200, Brice Goglin wrote:
> ...
> > > I have now downgraded the following packages:
> > > apt-get install xserver-xorg-core=2:1.1.1-21 xserver-xorg=1:7.1.0-16
> > > apt-get install xserver-xorg-video-ati (1:6.6.3-2 from Stable)
> > > With them all works OK!
> >
> > What about the new version of xserver-xorg-core with the old version of
> > xserver-xorg-video-ati?
>
> This was the original setup since version 1:6.6.3-2 is used by both
> stable and unstable.
Ah never mind, I took 'I have now downgraded the following packages'
literally.
> It seems I can upgrade xserver-xorg-core to 2:1.3.0.0.dfsg-5 without
> upgrading xserver-xorg to 1:7.2-3 but do you really think the problem
> is in xserver-xorg-7.2?
No, xserver-xorg-core it seems to be. The thing is, there were only
small changes in its Xv code between those two versions. Although there
was a known regression fixed by the attached patch, its only known
symptom is a server which only happens with a driver hook not used by
the ati driver. You may still want to try the patch though.
Also, your description of the problem sounds like it might be related to
the colour key. What does
xvinfo|grep -A2 COLORKEY
say when the problem occurs?
Last but not least, it might be helpful if you could capture the problem
with a digital camera or something.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
diff --git a/hw/xfree86/common/xf86xv.c b/hw/xfree86/common/xf86xv.c
index 2b097d2..02fcde6 100644
--- a/hw/xfree86/common/xf86xv.c
+++ b/hw/xfree86/common/xf86xv.c
@@ -979,6 +979,9 @@ xf86XVEnlistPortInWindow(WindowPtr pWin, XvPortRecPrivatePtr portPriv)
winPriv->next = PrivRoot;
pWin->devPrivates[XF86XVWindowIndex].ptr = (pointer)winPriv;
}
+
+ portPriv->pDraw = (DrawablePtr)pWin;
+
return Success;
}
@@ -1375,7 +1378,6 @@ xf86XVPutVideo(
result = xf86XVEnlistPortInWindow((WindowPtr)pDraw, portPriv);
if(result != Success) return result;
- portPriv->pDraw = pDraw;
portPriv->type = XvInputMask;
/* save a copy of these parameters */
@@ -1479,7 +1481,6 @@ xf86XVPutStill(
xf86XVEnlistPortInWindow((WindowPtr)pDraw, portPriv);
portPriv->isOn = XV_ON;
- portPriv->pDraw = pDraw;
portPriv->drw_x = drw_x; portPriv->drw_y = drw_y;
portPriv->drw_w = drw_w; portPriv->drw_h = drw_h;
portPriv->type = 0; /* no mask means it's transient and should
@@ -1529,7 +1530,6 @@ xf86XVGetVideo(
result = xf86XVEnlistPortInWindow((WindowPtr)pDraw, portPriv);
if(result != Success) return result;
- portPriv->pDraw = pDraw;
portPriv->type = XvOutputMask;
/* save a copy of these parameters */
@@ -1784,7 +1784,6 @@ xf86XVPutImage(
(portPriv->AdaptorRec->flags & VIDEO_OVERLAID_IMAGES)) {
portPriv->isOn = XV_ON;
- portPriv->pDraw = pDraw;
portPriv->drw_x = drw_x; portPriv->drw_y = drw_y;
portPriv->drw_w = drw_w; portPriv->drw_h = drw_h;
portPriv->type = 0; /* no mask means it's transient and should
Bug#421418: No XV here too
Please post a full log file from starting the X server without the VideoRam directive. Here it is (attached). An extract that I find relevant : (II) intel(0): I830CheckAvailableMemory: 440316 kB available (==) intel(0): VideoRam: 131072 KB (II) intel(0): Allocating 5472 scanlines for pixmap cache (II) intel(0): Memory allocation layout: (II) intel(0): 0x-0x0001: ring buffer (128 kB) (II) intel(0): 0x0002-0x00027fff: logical 3D context (32 kB) (II) intel(0): 0x0003-0x02127fff: front buffer (33760 kB) (II) intel(0): 0x007df000:end of stolen memory (II) intel(0): 0x02128000-0x02137fff: xaa scratch (64 kB) (II) intel(0): 0x0800:end of aperture (II) intel(0): front buffer is not tiled (WW) intel(0): Disabling Xv because the overlay register buffer allocation failed. Xorg.0.log.gz Description: GNU Zip compressed data
Bug#425969: XRecordEnableContextAsync work in lenny but not in sid.
Package: xorg
Version: 1:7.2-3
XRecordEnableContextAsync works well with lenny up to date (xorg
1:7.1.0-18) but not with sid up to date (xorg 1:7.2-3
) on the same computer.
XRecordEnableContext works on twice.
I attach a little piece of code that work on lenny but not sid.
If you replace XRecordEnableContextAsync with XRecordEnableContext and remove
XRecordProcessReplies it work on sid too, but the record is
synchronous now and cannot be integrated in an interactive gui app.
I'm not sure which of XRecordEnableContextAsync and
XRecordProcessReplies doesn't do it's job correctly.
To reproduce the bug, build the code with gcc main.c -lX11 -lXtst, run
it and move the mouse. if it work, it should catch the mouse motion
and print it on stdout.
#include
#include
#include
#include
#include
typedef union {
unsigned chartype ;
xEvent event ;
xResourceReq req ;
xGenericReplyreply ;
xError error ;
xConnSetupPrefix setup;
} XRecordDatum ;
int click = 0;
int press = 0;
int release = 0;
int other = 0;
int event = 0;
int button1down = 0;
int button2down = 0;
int button3down = 0;
int distance = -1;
int oldX = 0;
int oldY = 0;
void dispatch(XPointer pointer, XRecordInterceptData *data)
{
if ((data==NULL) || (!data->data))
{
XRecordFreeData(data);
return;
}
++event;
XRecordDatum *xrec_data = (XRecordDatum *) data->data;
if (data->category == XRecordFromServer)
{
switch (xrec_data->type)
{
case MotionNotify:
if (distance >= 0)
{
int x = xrec_data->event.u.keyButtonPointer.rootX - oldX;
int y = xrec_data->event.u.keyButtonPointer.rootY - oldY;
distance += x*x + y*y;
}
else
{
distance = 0;
}
oldX = xrec_data->event.u.keyButtonPointer.rootX;
oldY = xrec_data->event.u.keyButtonPointer.rootY;
break;
case ButtonPress:
if (xrec_data->event.u.u.detail == Button1)
{
button1down = 1;
}
else if (xrec_data->event.u.u.detail == Button2)
{
button2down = 1;
}
else if (xrec_data->event.u.u.detail == Button3)
{
button3down = 1;
}
break;
case ButtonRelease:
if (xrec_data->event.u.u.detail == Button1)
{
if (button1down)
{
click++;
}
button1down = 0;
}
else if (xrec_data->event.u.u.detail == Button2)
{
if (button2down)
{
click++;
}
button2down = 0;
}
else if (xrec_data->event.u.u.detail == Button3)
{
if (button3down)
{
click++;
}
button3down = 0;
}
break;
}
}
else
{
++other;
}
XRecordFreeData(data);
printf("Events n°%i ** clicks : %i ** distance : %i ** other : %i\n", event, click, distance, other);
}
int main(int argc, char **argv)
{
char *display_name = getenv ("DISPLAY");
Display *dpy = XOpenDisplay(display_name);
if (!dpy)
{
// unable to open display
printf("fail to open display\n");
return -1;
}
XRecordClientSpec xrcs[1];
xrcs[0] = XRecordAllClients;
XRecordRange *xr_range = XRecordAllocRange();
XRecordRange *xr_array[1];
xr_array[0] = xr_range;
if (!xr_range)
{
printf("fail to create range\n");
XCloseDisplay(dpy);
return -1;
}
xr_range->delivered_events.first = ButtonPress;
xr_range->delivered_events.last = MotionNotify;
XRecordContext xrc = XRecordCreateContext(
dpy,
XRecordFromServerTime,
xrcs,
1,
xr_array,
1
);
int res = XRecordEnableContextAsync(dpy, xrc, dispatch, 0);
if (res != 0)
{
printf("XRecord enabled\n");
while (click <= 10)
{
XRecordProcessReplies(dpy);
}
}
else
{
printf("fail to work\n");
}
XRecordDisableContext(dpy, xrc);
XRecordFreeContext(dpy, xrc);
XFree(xr_range);
XCloseDisplay(dpy);
printf("quit\n");
return 0;
}
Bug#421418: No XV here too
On Fri, 2007-05-25 at 10:32 +0200, Alexandre Rossi wrote: > > Please post a full log file from starting the X server without the > > VideoRam directive. > > Here it is (attached). > > An extract that I find relevant : > (II) intel(0): I830CheckAvailableMemory: 440316 kB available > (==) intel(0): VideoRam: 131072 KB > (II) intel(0): Allocating 5472 scanlines for pixmap cache > (II) intel(0): Memory allocation layout: > (II) intel(0): 0x-0x0001: ring buffer (128 kB) > (II) intel(0): 0x0002-0x00027fff: logical 3D context (32 kB) > (II) intel(0): 0x0003-0x02127fff: front buffer (33760 kB) > (II) intel(0): 0x007df000:end of stolen memory > (II) intel(0): 0x02128000-0x02137fff: xaa scratch (64 kB) > (II) intel(0): 0x0800:end of aperture > (II) intel(0): front buffer is not tiled > (WW) intel(0): Disabling Xv because the overlay register buffer > allocation failed. Does this also happen if you don't use Option "SWcursor" or enable the DRI? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#394318: Bug#399877 closed by Brice Goglin <[EMAIL PROTECTED]> (Bug#394318: xserver-xorg-core: XkbGetKeyboard() is broken)
What about Stable Etch? The bug isn't fixed in Etch, people using Etch can't run DOSEmu properly with accented characters, etc.., and that will happen for 1 year and a half? Thanks for your consideration. -- Ivan Baldo - [EMAIL PROTECTED] - http://ibaldo.codigolibre.net/ ICQ 10215364 - Phone/FAX (598) (2) 613 3223. Caldas 1781, Malvin, Montevideo, Uruguay, South America. We believe that we are free, but in reality we are not! Are we? Alternatives: [EMAIL PROTECTED] - http://go.to/ibaldo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394318: Bug#399877 closed by Brice Goglin <[EMAIL PROTECTED]> (Bug#394318: xserver-xorg-core: XkbGetKeyboard() is broken)
Ivan Baldo wrote: >What about Stable Etch? >The bug isn't fixed in Etch, people using Etch can't run DOSEmu > properly with accented characters, etc.., and that will happen for 1 > year and a half? Unfortunately, we can't take the risk of backporting such a big fix in Etch just to fix DOSemu. Only critical bugs and security holes justify an update of a stable release. People using Etch may still backport the fix in Xserver 1.1.1 and rebuild it, or upgrade to Xserver >= 1.2.0. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425969: XRecordEnableContextAsync work in lenny but not in sid.
Cédric wrote: > Package: xorg > Version: 1:7.2-3 > > XRecordEnableContextAsync works well with lenny up to date (xorg 1:7.1.0-18) > but not with sid up to date (xorg 1:7.2-3 > ) on the same computer. > XRecordEnableContext works on twice. > > I attach a little piece of code that work on lenny but not sid. > There's no actual code in the xorg package, upgrading this single package cannot break like this. The problem is probably caused by the upgrade of another package. XRecordEnableContextAsync is defined in libxtst, but there is no difference between lenny and sid for this package (both have 1:1.0.1-5). Same for libx11 (2:1.0.3-7). Could it be related to xserver-xorg-core (2:1.1.1-21 in lenny, 2:1.3.0.0.dfsg-5 in sid)? Brice
Bug#425969: XRecordEnableContextAsync work in lenny but not in sid.
Le vendredi 25 mai 2007, Brice Goglin a écrit : > Cédric wrote: > > Package: xorg > > Version: 1:7.2-3 > > > > XRecordEnableContextAsync works well with lenny up to date (xorg > > 1:7.1.0-18) but not with sid up to date (xorg 1:7.2-3 ) on the same > > computer. > > XRecordEnableContext works on twice. > > > > I attach a little piece of code that work on lenny but not sid. > > There's no actual code in the xorg package, upgrading this single > package cannot break like this. The problem is probably caused by the > upgrade of another package. Of course, but when I said xorg 1:7.2-3 up to date, I mean with all dependencies ;) and since I didn't know which part of xork is responsible, I fill a bug on xorg ! > XRecordEnableContextAsync is defined in > libxtst, but there is no difference between lenny and sid for this > package (both have 1:1.0.1-5). Same for libx11 (2:1.0.3-7). Could it be > related to xserver-xorg-core (2:1.1.1-21 in lenny, 2:1.3.0.0.dfsg-5 in > sid)? I think it could be xserver-xorg-core too since is the only one that is upgraded between lenny and sid. But I just see that I use libxi6 from experimental :/ here the system informations get from reportbug : -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xorg depends on: ii konsole [x-terminal-emulato 4:3.5.7-1X terminal emulator for KDE ii libgl1-mesa-glx 6.5.2-5 A free implementation of the OpenG ii libglu1-mesa6.5.2-5 The OpenGL utility library (GLU) ii type-handling [not+sparc] 0.2.21 dpkg architecture generation scrip ii xbase-clients 1:7.2.ds2-2 miscellaneous X clients ii xfonts-100dpi 1:1.0.0-3100 dpi fonts for X ii xfonts-75dpi1:1.0.0-375 dpi fonts for X ii xfonts-base 1:1.0.0-4standard fonts for X ii xfonts-scalable 1:1.0.0-6scalable fonts for X ii xkb-data0.9-4X Keyboard Extension (XKB) configu ii xorg-docs 1:1.4-1 Miscellaneous documentation for th ii xserver-xorg1:7.2-3 the X.Org X server ii xterm [x-terminal-emulator] 225-1X terminal emulator ii xutils 1:7.1.ds.3-1 X Window System utility programs Versions of packages xorg recommends: ii libgl1-mesa-dri 6.5.2-5A free implementation of the OpenG -- no debconf information Let me know if you need more informations / test / other > > Brice
Processed: reassign 425969 to xserver-xorg-core
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.2 > reassign 425969 xserver-xorg-core Bug#425969: XRecordEnableContextAsync work in lenny but not in sid. Bug reassigned from package `xorg' to `xserver-xorg-core'. > End of message, 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]
Bug#324777: ctrl, atl, shift, and alt-gr don't work
Hi, About 2 years ago, you reported (or replied to) a bug in the Debian BTS regarding alt, ctrl, shift, and alt-gr not working. Did any of you guys reproduce this problem recently? With Xorg/Etch? If not, I will close this bug in the next weeks. Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376951: Problems with Emacs fonts
Hi, About a year ago, you reported a bug to the Debian BTS regarding problems with emacs fonts. Did you reproduce this problem recently? With Xorg/Etch? If not, I will close this bug in the next weeks. Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344776: Incorrect Speedo/fonts.dir leads to incorrect font selection
reassign 344776 xfonts-utils forcemerge 365984 344776 thank you Since this bug seems to be caused to fonts.dir not being updated when fonts are removed, I am merging this bug with #365984 against xfonts-utils. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Bug#344776: Incorrect Speedo/fonts.dir leads to incorrect font selection
Processing commands for [EMAIL PROTECTED]: > reassign 344776 xfonts-utils Bug#344776: Incorrect Speedo/fonts.dir leads to incorrect font selection Bug reassigned from package `xorg' to `xfonts-utils'. > forcemerge 365984 344776 Bug#365984: xfonts-base: old font dirs in /usr/X11R6/lib/X11/fonts not removed Bug#344776: Incorrect Speedo/fonts.dir leads to incorrect font selection Bug#362312: junk left in /usr/X11R6/lib/X11/fonts after upgrade Forcibly Merged 344776 362312 365984. > thank you 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]
Bug#413594: xorg: glitches in font configuration make some fonts unusable
Hi Jiri, Did you get anything new about this bug regarding unusable fonts in Xft applications after upgrading Xorg? Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Bug#390162: xorg: conflicting locale settings and keyboard input
Processing commands for [EMAIL PROTECTED]: > tags 390162 +unreproducible Bug#390162: xorg: conflicting locale settings and keyboard input There were no tags set. Tags added: unreproducible > thank you 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]
Bug#390162: xorg: conflicting locale settings and keyboard input
tags 390162 +unreproducible thank you Hi Pascal, Several months ago, you reported a bug to the Debian BTS regarding locale problems when mixing utf8 and iso-8859-1. I have been told that the problem could not be reproduced. Did you reproduce it recently? With Xorg/Etch? Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#415543: xorg: xserver crashes on beige G3 PowerMac
Hi Rick, Could you send the output of /usr/share/bug/xserver-xorg-core/script 3>&1 so that we also see all details about your machine and config? It looks like you are using the fbdev driver on an ATI board. Did you try the ATI driver? Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388699: Proposed solutions.
Hello All: I also suffered of this problem. After the research I did, I reckon that the problem was that after a suspend to ram (STR) the xorg driver didn't issue a POST on the video card and even changing to a VT and back to X didn't work. But this behaviour only happens in the etch i810 Xorg driver. On the current unstable, the intel does this seaminglessly. There was a tool called video-post which I've found now here: http://www.srcf.ucam.org/~mjg59/laptops/ It performs a quite aggresive POST which should be done on a text console. This is the more direct way to do video POST. You could also get a video POST obviously by hibernating to disk (= powering off) and then resuming (= poweing on) as Drew suggested. You could use the UseDummyXserver option in the hibernate scripts which would launch a dummy server which hopefully will do a POST somehow. The problem is this is slow and problem prone, at least in my experience. What I had found to work better was using the EnableVbeTool and the VbetoolPost, or maybe some other VbeTools options depending on your system. More info on /usr/share/hibernate/scriptlets.d/vbetool. IMHO this is the smarter and most effective way, but beware of using the SwitchToTextMode and/or UseDummyXServer together with the vbetool options. What you need is combination of them and unfortunately experience will tell you what works better. Good luck! As this problem is still addressed and solved on the intel driver 2.0 I suggest closing this bug. Regards, -- Raúl Sánchez Siles ->Proud Debian user<- Linux registered user #416098 signature.asc Description: This is a digitally signed message part.
Bug#324777: ctrl, atl, shift, and alt-gr don't work
Hi Brice, It's fixed for me. I'm using Lenny, so I don't know about Etch. ii debconf 1.5.13Debian configuration management system ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii x11-common7.1.0-18 X Window System (X.Org) infrastructure ii xorg 7.1.0-18 X.Org X Window System David On 26/05/07, Brice Goglin <[EMAIL PROTECTED]> wrote: Hi, About 2 years ago, you reported (or replied to) a bug in the Debian BTS regarding alt, ctrl, shift, and alt-gr not working. Did any of you guys reproduce this problem recently? With Xorg/Etch? If not, I will close this bug in the next weeks. Thanks, Brice -- Mau ki ana, he aha te mea nui? You ask, "What is the most important thing?" Maku ki ana, he tangata, he tangata, he tangata. I reply, "It is people, it is people, it is people."
Processed: Re: Bug#426061: xfonts-bitmap-mule: warning upon upgrade
Processing commands for [EMAIL PROTECTED]: > reassign 426061 xfonts-utils 1:1.0.1-1 Bug#426061: xfonts-bitmap-mule: warning upon upgrade Bug reassigned from package `xfonts-bitmap-mule' to `xfonts-utils'. > severity 426061 normal Bug#426061: xfonts-bitmap-mule: warning upon upgrade Severity set to `normal' from `wishlist' > merge 426061 405671 Bug#405671: (obsolete?) "/usr/lib/X11/fonts/Type1" should be "/usr/share/fonts/X11/Type1" Bug#426061: xfonts-bitmap-mule: warning upon upgrade Bug#389085: xfonts-utils: issues warnings if /usr/lib/X11/fonts/Type1 doesn't exist Bug#400449: warnings while installing Merged 389085 400449 405671 426061. > 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]
