Re: how to convert a window ID to a linux process ID?
dave giffin wrote: > > > I need to be able to tell which process a given window > was created by. (Window ID=>Process ID) > > Apparently, X servers don't know which process a > client is, they just get a socket (b/c of X's network > transparency). > > It has been suggested that I could run a program like > netstat on the client machine(which in my case is the > same machine running the server) to get a list of > which sockets belong to which processes. > > Then, I need to get the ID of the foreign socket > (socket ID on client end) from which a window was > created. > > What would work well is if the socket ID and the > client/window ID could be written to STDOUT or STDIN > when the window is created. Then I can have a script > read the server's STDOUT or STDIN and compare it to > the list of socket IDs and process IDs from netstat on > the client machine (which for my purposes is on the > same machine as the server). > > MY PROBLEM: I don't know how to get XFree86 to write > the socket ID and client ID when a window is created! > > Today, I was looking at the XFree86(4.3.0) source code > for the first time and trying some different hacks to > get the info I wanted to print. > > In xc/programs/Xserver/dix/dispatch.c, I found > ProcCreateWindow and the ClientPtr structure. I was > able to get X to print client->index and > client->OsPrivate->fd when a new window was created. > > Which is what I want, except that the client index > that is printed is always 2 and the socket ID is > always 13. 13 is the ID of the socket that X listens > on and I think 2 is the server client? > > What am I doing wrong? > > How can I print the Window ID and foreign/from socket > ID of a client when a window is created? > > :) thanx This does indeed sound like the 'hard way'... There has been some work on various window manager projects to tie this information together. For example, in the development code for enlightenment, the direction taken was to tag application windows on launch with their process id as a property. Then the window manager has no trouble retrieving this information at a later time. Would something like that work for you? Or is there some reason you feel it needs to be done at the xfree86 level? -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: "nv" driver obscurities...
"Mike A. Harris" wrote: > > > On Fri, 7 Nov 2003, Mark Vojkovich wrote: > > >> Everywhere > >> in the driver hex values are given premultiplied by 4 it seems, > >> and specified as VALUE/4. > > > > The register pointers are dword pointers. The register offsets > >are byte offsets. They are written as VALUE/4 so that I can grep > >for VALUE. This is done so that it's easier for me to maintain. > >Converting everything to dword offsets will make my job more > >difficult. > > Ah, ok. > > > I'm not sure why you are bringing this up. > > I'm bringing it up because I have no idea how Nvidia hardware > works, have no Nvidia documentation, the source code of the > driver is quite obfuscated by not using symbolic names for > things, and that was one obfuscation that I thought might be > something that could be cleaned up. Having no way of knowing why > it is coded the way it is other than making a random guess, or by > asking someone who does know, how is one supposed to find out why > it is coded this way? > > >I would think it would be obvious that since I am maintaining > >it, it would be in the form that is easiest for me to maintain. > > Sure, that works fine for me if that is the case, at least once > it is known that there is a valid reason, and that it is done > intentionally. > > But don't assume that I can mind read the intentions of an > obfuscated driver. Would you prefer other developers and > potential developers did not ask questions at all, and instead > went off and worked on other projects? > > Seems every time someone asks for information on how something > works in the codebase that they don't understand, or asks for > clarification on something, they can't get a straight or clear > answer. > > It's really no wonder volunteers get put off from contributing to > the XFree86 project. Well, gee, Mike... You're question was filled with negative assumptions about why the driver might be 'obfuscated'. You shouldn't take offense if Mark is a little short with you. Focus on asking a question, leaving off the insinuations, and you'll get better answers. A shorter question like "I'd find it clearer if the nv driver used #defines for registers rather than hardcoded values. Does anyone object to changing it?" would tend to go over smoother. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: S3 Trio 3D Chip - 86C366 not recognized?
Shawn Starr wrote: > > > I have an IBM 300PL w/ an onboard Trio 3D Chip, the model does not appear to > be supported (?) > > When X loads, it won't allow resolution beyond 640x480, it drops back to > 640x480 regardless of how I configure. > > The chip information is as follows (from the chip): > > The model is a 86C366 looking at XFree86-HEAD from today from s3v_driver.c > in xc/programs/Xserver/hw/xfree86/drivers/s3virge there is no mention of > this chip model. Is this supported yet? It is extremely broken, ie, blit > corruption, invalid resolutions, lots of chip reset errors: > > Trio3D -- Display is on...turning off > Trio3D -- S3VNopAllCmdSets: SubsysStats#1 = 0x20007f80 > Trio3D -- S3VNopAllCmdSets: state changed after 0 iterations > Trio3D -- S3VNopAllCmdSets: SubsysStats#2 = 0x20007f80 > Trio3D -- GE was on ST#1: 0x20007f80 ST#2: 0x20007f80 > Trio3D -- S3VNopAllCmdSets: SubsysStats#1 = 0x0e115f80 > Trio3D -- S3VNopAllCmdSets: state DIDN'T changed after 1000 > iterations > Trio3D -- S3VNopAllCmdSets: SubsysStats#2 = 0x0d915f80 > S3VGEReset called from s3v_accel.c line 410 > Trio3D -- GE was on ST#1: 0x0d915f80 ST#2: 0x0d915f80 > restarting S3 graphics engine reset 1 ...d115f80 > Trio3D -- GE was on ST#1: 0x0d115f80 ST#2: 0x0d115f80 > restarting S3 graphics engine reset 2 ...c915f80 > Trio3D -- GE was on ST#1: 0x0c915f80 ST#2: 0x0c915f80 > restarting S3 graphics engine reset 3 ...c115f80 > Trio3D -- GE was on ST#1: 0x0c115f80 ST#2: 0x0c115f80 > > The full information on the chip is as follows: > > NDC0BB > 86C366 > 9933 CA925.00 > S3 Trio3D > On Board (tm) > > Anyone else has this chip? > > Included is the XFree86.0.log from /var/log. Interesting... Are you sure it's a 86C366 and not a 365? The reported pci id matches the 365. Have you tried using the "novbe" or "noddc" options and configuring the monitor section by hand? It looks like the resolution is being limited by the automatic setup of vertical and horiz refresh. We've had reports of the Trio3D working, but I don't have one personally. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VideoRAM option
Dr Andrew C Aitchison wrote: > > > On Wed, 1 Oct 2003, Mike A. Harris wrote: > > > If people (both other developers and end users) who _require_ > > the VideoRAM option in order for the proper amount of video > > memory to be useable with their card, could send me privately > > their: "lspci -vvn" or alternatively "scanpci" output (if lspci > > isn't available to them), that would help me assess how feasible > > this would be to do. > > The Millennium II cannot be probed; MGACountRam() claims it is a > hardware bug. As far as I know this function correctly detects the > cases it can't handle, and I don't have an accessible card to provide > lspci output. > > > My end-goal here, is to determine which hardware truely requires > > the VideoRAM option, and limit the usage of that option in our > > own XFree86 packages to those specific drivers and cards to limit > > the amount of bogus incoming bug reports and end user problems > > created by unnecessary overconfiguration. I might also add > > another option to re-enable VideoRAM override if people see cases > > where autodetection does work, but want to override it anyway, > > such as a global "AllowVideoRAMOverride" setting. ie: user has > > card with bad videoram, but by limiting videoram to a lower > > amount they can disable the bad area of memory. > > Would it be good enough to make the probed value override any > larger amount specified by the user ? > I'm not sure whether breaking the convention that user config > overrides probed values is a good idea or not here. Well, it seems that this is a case of trying to fix the problem in the wrong place. Mike admits that some config tools make it entirely to easy to change the videoram setting, and then proposes that it be worked around by changing a fairly long standing methodology in the video drivers. Possibly adding a second option to override it. I vote for working on fixing the config tools instead. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VideoRAM option
Tim Roberts wrote: > > > On Thu, 2 Oct 2003 08:07:31 -0600 (MDT), Marc Aurele La France wrote: > > > >On Wed, 1 Oct 2003, Marc Aurele La France wrote: > > > >> > My goal is to disable this option by default in drivers which > >> > correctly detect video memory on all supported cards, at least > >> > for our shipped drivers. I've disabled this setting in our > >> > radeon driver for example as that driver correctly detects video > >> > memory on all supported hardware. > > > >> The atimisc module has been VideoRAM specifications for a long time. In > > ^ > >Finger check:ignoring > > > >> the case of ATI adapters at least, if the driver doesn't properly detect > >> video memory size, I'd consider it a bug. > > The S3 Savage driver also ignores VideoRAM. Every known Savage BIOS sets > the RAM size in a scratch register, and since VIA isn't making any new > Savages, "every known BIOS" can now be interpreted as "every BIOS". This was also true of s3virge up to about a year ago. But I've finally run into a couple reports of mis-detected video ram. It seems a couple laptops do not have the bits wired correctly or something. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Any way to intercept background painting in Xv?
I'm not sure how stopping the color key painting will help accomplish your goal here. It may be possible to grab the background data from the screen position, pre-blend it into your video image, and then display it as part of the video stream. However that will take quiet a bit of pre-processing. And you would still want to use color keying to accelerate the video display. Some hardware does support blending of the overlay against background data, I'm not sure if that could be used or not. -- Kevin Wei Chong wrote: > > > I would like to make my Xvideo appear translunent by > using alpha blending of my video image against the > "desktop background". However, each time before the > before any of the Xv PutImage() is invoked, after the > window is created, it appears that the background of > the window has already been painted to some color, > like black. I would like to prevent such things from > happening. > > Thanks, > Wei-Chong Tan. > > --- Mark Vojkovich <[EMAIL PROTECTED]> wrote: > >Perhaps you could explain what you are trying to > > do? > > The driver itself is responsible for painting the > > color > > key, and automatic painting of the key is usually > > optional behavior. One gets the idea that whatever > > you > > are trying to do, you are going about it the wrong > > way. > > > > > > Mark. > > > > On Sun, 28 Sep 2003, Wei Chong wrote: > > > > > Hello, > > > > > > I would like to know which function is responsible > > to > > > paint the window's background colorkey before any > > > video image is display in the XVideo extension? > > > > > > I did a crash in my PutImage() to see the stack > > trace > > > but i only see... > > > main() --> Dispatch() --> ErrorMessage() --> > > > xf86PutImage() --> my PutImage(). > > > > > > I looked into xf86PutImage() but didn't see any > > code > > > that actually paint the window's background color. > > I > > > would like to either: > > > 1. Intercept the code that do actual painting and > > > refrain it from doing so. > > > OR > > > 2. Obtain a snapshot of the background image being > > > written over by the painting process before it > > occurs. > > > > > > Thanks, > > > Wei-Chong. > > > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Help on creating a Window Manager
Havoc Pennington wrote: > > > On Sun, Aug 31, 2003 at 08:59:39PM +0200, Peter Poulsen wrote: > > > > I'm playing around with xlib, and is trying to make a window manager > > (just because I can ;-)). But the problem is that I need a little more > > information. Is there some good resources anybody know of? Also, is > > there a mailing list that is more suited for questions related to the > > use of xlib (as far as I understand this mailing list is conserned with > > the development of xfree, rather than the use of xlib)? > > The main resources are the ICCCM, the EWMH, and the source code of > other window managers. twm is small and simple to learn from, though > doesn't support the newer EWMH spec. > > Don't try to read the WM chapter in the Nye book, it's mostly wrong. > You'll find http://www.freedesktop.org/standards/ helpful, it has copies of most of these standards. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Make install blows away startup files?
Kendall Bennett wrote: > > > Kevin Brosius <[EMAIL PROTECTED]> wrote: > > > Depends somewhat on how RH does X init. You can look through > > startx and xinit setup and see what's being changed. > > Isn't the installer supposed to not replace xinit.rc if the file already > exists? That is what the comment in the xf86site.def file says, but that > would appear not to be the case? Well, /etc/X11/xinit/xinitrc certainly wasn't updated during my last 'make install'. Assuming you logged the install, you'll be able to tell exactly what was written. Mine has the following: - make[3]: Entering directory `/usr/local/src/xc-cvs/xc/programs/xinit' install -c xinit /usr/X11R6/bin/xinit install -c -m 0755 startx /usr/X11R6/bin/startx Not overwriting existing /usr/X11R6/lib/X11/xinit/xinitrc install in programs/xinit done -- -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Make install blows away startup files?
Kendall Bennett wrote: > > > Hi Guys, > > I have been mass compiling and installing multiple versions of XFree86 > onto a machine for compatibility testing (Red Hat 7.3 based, so I can use > the GDB hacked up debugger ;-). However whenever I do a 'make install' > from a freshly built 4.2.0, 4.2.1 or 4.3.0 (haven't done any ealier > versions yet ;-), it always blows away something in the startup files so > when I do a 'startx', all I get is a desktop with three console windows > open (seems to be using twm as the window manager). If I copy all the > files from the original Red Hat 7.3 /etc/X11 directory across, it starts > up just fine using the GNOME desktop. > > Firstly, I don't know what file is being destroyed or replaced. Does > anyone know what file is getting replaced? Secondly it seems to me that a > 'make install' should be non-destructive and should not be changing this > file. I have not changed any of the defaults in the host.def file, so it > seems to me that it is bug that after a make install over the top of an > existing XFree86 install, XFree86 no longer functions the way it did > before. > > Is there an option to fix this in the host.def file? If so, perhaps this > should be the default option when doing a make install?? > > BTW, I am using a script to symlink /usr/X11R6 and /etc/X11 for each > version so I can switch between all versions with a simple command ;-) Depends somewhat on how RH does X init. You can look through startx and xinit setup and see what's being changed. I know on SuSE that 'make install' breaks the KDM/xdm startup, and that they use a WINDOWMANAGER environment variable in their X init pieces. If you don't have that variable set, then you'll get either no wm or twm. But doing a source install over your distro's install tree is really up to you to resolve. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: notes on SonicBlue (S3) and S3TC
I don't have any terribly recent info, but s3graphics was still under the Via umbrella last time I checked. They had docs available as long as you were willing to sign an NDA. The NDA allows source code release, so is compatible with XFree86 development. -- Kevin Alex Deucher wrote: > > > what's the status of S3/sonicblue/VIA? who owns what? I'd really like > to get savage mx/ix specs, but I fear that possiblity is slipping away > :( > > Alex > > --- Alexander Stohr <[EMAIL PROTECTED]> wrote: > > Hmm, SonicBlue (aka known as S3) has claimed > > bankrupcy (Chapter 11) recently, so its a changing > > situation with S3TC compression right now - > > who will ever buy that patent and charge the world > > for the next 70 years? > > > > Of course the prefered solution would be that some > > interested circles buy it as a group and then open > > that technology for offering to the world for free. > > > > -Alex. > > > > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[PATCH] Re: xmag segv's
Yeah, that's what it's trying to do. The problem is it doesn't check
the first child of root for InputOnly, only 2nd children on up. E17 has
an InputOnly window as the first child of root, which breaks xmag. I'd
suggest the following patch. It checks to make sure all children are
InputOutput and will only return one that is, or the root. (I suspect
that was the original intent.)
I've also included fixes for the null pointer dereferences exhibited
when the above code failed. What do you think?
Summary of change:
Fix case in xmag which would cause a BadMatch during a X_GetImage for
single child of root class InputOnly. Also do some null pointer
protection.
--
Kevin
Mark Vojkovich wrote:
>
>
> On Wed, 26 Feb 2003, Kevin Brosius wrote:
>
> > The background reports "Depth: 0" with xwininfo. That looks like a
> > problem.
> >
> > The x,y,... to the GetImage seem good, 1103,302,64,64.
>
>What does xwininfo say the "Class" is? It should be InputOnly.
> Depth 0 windows are InputOnly.
>
>Can you poke around in xmag's FindWindow? Maybe the logic
> in there is busted. I'm not really following what it's supposed
> to be doing. Looks like it starts at the root and works it's way
> towards the pointer (out of the screen) until the last InputOutput
> window, which is the only type it can grab from. I would guess it
> wants the frontmost InputOutput window under the pointer.
>
> Mark.
>
> >
> > --
> > Kevin
> >
> >
> > Mark Vojkovich wrote:
> > >
> > >
> > >Are there depth 32 windows or something? If not
> > > GetImageAndAttributes should call XGetImage on the
> > > root window. It looks like the checks in there are OK.
> > > Can you check the x,y,width,height to that first XGetImage
> > > in GetImageAndAttributes?
> > >
> > > Mark.
> > >
> > > On Tue, 25 Feb 2003, Kevin Brosius wrote:
> > >
> > > > Of course, that's not what causes the X_GetImage failure... That
> > > > happens here:
> > > >
> > > > in DragEH()
> > > >
> > > > case ButtonRelease: /* end drag mode */
> > > > if (event->xbutton.button == Button1) { /* get image */
> > > > /* Problem: You can't get bits with XGetImage outside of its
> > > > window.
> > > >* xmag will only do a GetImage on the actual window in
> > > > the case
> > > >* where the depth of the window does not match the depth
> > > > of
> > > > * the root window.
> > > >*/
> > > > GetImageAndAttributes(FindWindow(event->xmotion.x_root,
> > > > event->xmotion.y_root),
> > > > event->xbutton.x_root,
> > > > event->xbutton.y_root,
> > > > srcWidth, srcHeight, data);
> > > >
> > > > the GetImage call above generates the BadMatch. The embedded
> > > > FindWindow() calls seem to succeed.
> > > >
> > > > Kevin Brosius wrote:
> > > > >
> > > > > Latest CVS xmag (yesterday, changelog at 948.) No, there's no overlay,
> > > > > this is on an ATI Mach64 at depth 16. I do think e17 uses a virtual
> > > > > root window however. Here's the problem:
> > > > >
> > > > > (gdb) r
> > > > > X Error of failed request: BadMatch (invalid parameter attributes)
> > > > > Major opcode of failed request: 73 (X_GetImage)
> > > > > Serial number of failed request: 2375
> > > > > Current serial number in output stream: 2375
> > > > >
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
> > > > > (gdb) bt
> > > > > #0 0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
> > > > > #1 0x0804b7cf in PopupNewScale (data=0x805b5b8) at xmag.c:975
> > > > > #2 0x0804a909 in DragEH (w=0x805fc38, closure=0x805b5b8,
> > > > > event=0xb460, continue_to_dispatch=0xb38f
> > > > > "\001`ôÿ¿8ü\005\bdf\005\b8·\005\b\a") at xmag.c:664
> > > > > #3 0x400accf4 in XtDispatchEventToWidget () from
> > > > > /usr/X11R6/lib/libXt.so.6
> > > > > #4 0x4
Re: xmag segv's
The background reports "Depth: 0" with xwininfo. That looks like a
problem.
The x,y,... to the GetImage seem good, 1103,302,64,64.
--
Kevin
Mark Vojkovich wrote:
>
>
>Are there depth 32 windows or something? If not
> GetImageAndAttributes should call XGetImage on the
> root window. It looks like the checks in there are OK.
> Can you check the x,y,width,height to that first XGetImage
> in GetImageAndAttributes?
>
> Mark.
>
> On Tue, 25 Feb 2003, Kevin Brosius wrote:
>
> > Of course, that's not what causes the X_GetImage failure... That
> > happens here:
> >
> > in DragEH()
> >
> > case ButtonRelease: /* end drag mode */
> > if (event->xbutton.button == Button1) { /* get image */
> > /* Problem: You can't get bits with XGetImage outside of its
> > window.
> >* xmag will only do a GetImage on the actual window in
> > the case
> >* where the depth of the window does not match the depth
> > of
> >* the root window.
> >*/
> > GetImageAndAttributes(FindWindow(event->xmotion.x_root,
> > event->xmotion.y_root),
> > event->xbutton.x_root,
> > event->xbutton.y_root,
> > srcWidth, srcHeight, data);
> >
> > the GetImage call above generates the BadMatch. The embedded
> > FindWindow() calls seem to succeed.
> >
> > Kevin Brosius wrote:
> > >
> > > Latest CVS xmag (yesterday, changelog at 948.) No, there's no overlay,
> > > this is on an ATI Mach64 at depth 16. I do think e17 uses a virtual
> > > root window however. Here's the problem:
> > >
> > > (gdb) r
> > > X Error of failed request: BadMatch (invalid parameter attributes)
> > > Major opcode of failed request: 73 (X_GetImage)
> > > Serial number of failed request: 2375
> > > Current serial number in output stream: 2375
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
> > > (gdb) bt
> > > #0 0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
> > > #1 0x0804b7cf in PopupNewScale (data=0x805b5b8) at xmag.c:975
> > > #2 0x0804a909 in DragEH (w=0x805fc38, closure=0x805b5b8,
> > > event=0xb460, continue_to_dispatch=0xb38f
> > > "\001`ôÿ¿8ü\005\bdf\005\b8·\005\b\a") at xmag.c:664
> > > #3 0x400accf4 in XtDispatchEventToWidget () from
> > > /usr/X11R6/lib/libXt.so.6
> > > #4 0x400ad767 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6
> > > #5 0x400ad944 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
> > > #6 0x400adea2 in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
> > > #7 0x0804bd43 in main (argc=1, argv=0xb554) at xmag.c:1105
> > > #8 0x402204a2 in __libc_start_main () from /lib/libc.so.6
> > > (gdb) l
> > >
> > > static Pixel
> > > GetMinIntensity(hlPtr data)
> > > {
> > > XColor *colors = NULL, *mptr, *tptr;
> > > int i, ncolors;
> > >
> > > if (data->win_info.colormap == DefaultColormap(dpy, scr))
> > > return BlackPixel(dpy, scr);
> > > ncolors = Get_XColors(&data->win_info, &colors);
> > > mptr = tptr = colors; tptr++;
> > >
> > > 903 for (i=1; i > > 904 if ((int)Intensity(mptr) > (int)Intensity(tptr))
> > > 905 mptr = tptr;
> > > 906 tptr++;
> > > 907 }
> > > 908 return mptr->pixel;
> > > 909 }
> > > 910
> > > (gdb) p ncolors
> > > $1 = 0
> > >
> > > I pasted some extra lines from the function in question. Get_XColors
> > > returns 0 in my case, and since mptr was set to NULL already, the return
> > > segv's when hit (the for loop falls through.) What should happen in
> > > this case? Can we just return BlackPixel like the previous test?
> > >
> > > --
> > > Kevin
> > >
> > > Mark Vojkovich wrote:
> > > >
> > > >
> > > >I don't see how the window manager could be involved. How
> > > > current of CVS? The last thing in the CHANGELOG on my machine is
> > > > 862 and I don't see this problem.
> > > >
> > > >I think BadMatch can happen with GetImage only if the app
> > > &g
Re: xmag segv's
Latest CVS xmag (yesterday, changelog at 948.) No, there's no overlay,
this is on an ATI Mach64 at depth 16. I do think e17 uses a virtual
root window however. Here's the problem:
(gdb) r
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 2375
Current serial number in output stream: 2375
Program received signal SIGSEGV, Segmentation fault.
0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
(gdb) bt
#0 0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
#1 0x0804b7cf in PopupNewScale (data=0x805b5b8) at xmag.c:975
#2 0x0804a909 in DragEH (w=0x805fc38, closure=0x805b5b8,
event=0xb460, continue_to_dispatch=0xb38f
"\001`ôÿ¿8ü\005\bdf\005\b8·\005\b\a") at xmag.c:664
#3 0x400accf4 in XtDispatchEventToWidget () from
/usr/X11R6/lib/libXt.so.6
#4 0x400ad767 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6
#5 0x400ad944 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#6 0x400adea2 in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
#7 0x0804bd43 in main (argc=1, argv=0xb554) at xmag.c:1105
#8 0x402204a2 in __libc_start_main () from /lib/libc.so.6
(gdb) l
static Pixel
GetMinIntensity(hlPtr data)
{
XColor *colors = NULL, *mptr, *tptr;
int i, ncolors;
if (data->win_info.colormap == DefaultColormap(dpy, scr))
return BlackPixel(dpy, scr);
ncolors = Get_XColors(&data->win_info, &colors);
mptr = tptr = colors; tptr++;
903 for (i=1; i (int)Intensity(tptr))
905 mptr = tptr;
906 tptr++;
907 }
908 return mptr->pixel;
909 }
910
(gdb) p ncolors
$1 = 0
I pasted some extra lines from the function in question. Get_XColors
returns 0 in my case, and since mptr was set to NULL already, the return
segv's when hit (the for loop falls through.) What should happen in
this case? Can we just return BlackPixel like the previous test?
--
Kevin
Mark Vojkovich wrote:
>
>
>I don't see how the window manager could be involved. How
> current of CVS? The last thing in the CHANGELOG on my machine is
> 862 and I don't see this problem.
>
>I think BadMatch can happen with GetImage only if the app
> trys to grab outside of the window. I think xmag grabs on the
> root window to avoid this, but can only do this when the depth
> of the window in question is the root depth. You don't have
> different depth windows do you (overlay, depth 32 windows).
> It looks like it knows how to clamp to the window dimensions.
>
>Maybe you can get a backtrace with a debug xmag?
>
> Maybe it has something to do with RandR?
>
> Mark.
>
> On Mon, 24 Feb 2003, Kevin Brosius wrote:
>
> > I've noticed the following xmag segv with current CVS when trying to
> > view part of the background in the development version of e (e17). Is
> > this an xmag or a window manager problem? (Or both?)
> >
> >
> > (gdb) r
> > X Error of failed request: BadMatch (invalid parameter attributes)
> > Major opcode of failed request: 73 (X_GetImage)
> > Serial number of failed request: 668
> > Current serial number in output stream: 668
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0804afbf in GetMinIntensity ()
> >
> > This only occurs when the start point of the xmag selection window is
> > over the background. Clicking inside an application works fine, as does
> > clicking inside but near an application edge which shows both
> > application and background image magnification. (I can magnify the
> > background as long as the click doesn't occur on it.)
> >
> > --
> > Kevin
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: xmag segv's
Of course, that's not what causes the X_GetImage failure... That
happens here:
in DragEH()
case ButtonRelease: /* end drag mode */
if (event->xbutton.button == Button1) { /* get image */
/* Problem: You can't get bits with XGetImage outside of its
window.
* xmag will only do a GetImage on the actual window in
the case
* where the depth of the window does not match the depth
of
* the root window.
*/
GetImageAndAttributes(FindWindow(event->xmotion.x_root,
event->xmotion.y_root),
event->xbutton.x_root,
event->xbutton.y_root,
srcWidth, srcHeight, data);
the GetImage call above generates the BadMatch. The embedded
FindWindow() calls seem to succeed.
Kevin Brosius wrote:
>
> Latest CVS xmag (yesterday, changelog at 948.) No, there's no overlay,
> this is on an ATI Mach64 at depth 16. I do think e17 uses a virtual
> root window however. Here's the problem:
>
> (gdb) r
> X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 73 (X_GetImage)
> Serial number of failed request: 2375
> Current serial number in output stream: 2375
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
> (gdb) bt
> #0 0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
> #1 0x0804b7cf in PopupNewScale (data=0x805b5b8) at xmag.c:975
> #2 0x0804a909 in DragEH (w=0x805fc38, closure=0x805b5b8,
> event=0xb460, continue_to_dispatch=0xb38f
> "\001`ôÿ¿8ü\005\bdf\005\b8·\005\b\a") at xmag.c:664
> #3 0x400accf4 in XtDispatchEventToWidget () from
> /usr/X11R6/lib/libXt.so.6
> #4 0x400ad767 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6
> #5 0x400ad944 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
> #6 0x400adea2 in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
> #7 0x0804bd43 in main (argc=1, argv=0xb554) at xmag.c:1105
> #8 0x402204a2 in __libc_start_main () from /lib/libc.so.6
> (gdb) l
>
> static Pixel
> GetMinIntensity(hlPtr data)
> {
> XColor *colors = NULL, *mptr, *tptr;
> int i, ncolors;
>
> if (data->win_info.colormap == DefaultColormap(dpy, scr))
> return BlackPixel(dpy, scr);
> ncolors = Get_XColors(&data->win_info, &colors);
> mptr = tptr = colors; tptr++;
>
> 903 for (i=1; i 904 if ((int)Intensity(mptr) > (int)Intensity(tptr))
> 905 mptr = tptr;
> 906 tptr++;
> 907 }
> 908 return mptr->pixel;
> 909 }
> 910
> (gdb) p ncolors
> $1 = 0
>
> I pasted some extra lines from the function in question. Get_XColors
> returns 0 in my case, and since mptr was set to NULL already, the return
> segv's when hit (the for loop falls through.) What should happen in
> this case? Can we just return BlackPixel like the previous test?
>
> --
> Kevin
>
> Mark Vojkovich wrote:
> >
> >
> >I don't see how the window manager could be involved. How
> > current of CVS? The last thing in the CHANGELOG on my machine is
> > 862 and I don't see this problem.
> >
> >I think BadMatch can happen with GetImage only if the app
> > trys to grab outside of the window. I think xmag grabs on the
> > root window to avoid this, but can only do this when the depth
> > of the window in question is the root depth. You don't have
> > different depth windows do you (overlay, depth 32 windows).
> > It looks like it knows how to clamp to the window dimensions.
> >
> >Maybe you can get a backtrace with a debug xmag?
> >
> >Maybe it has something to do with RandR?
> >
> > Mark.
> >
> > On Mon, 24 Feb 2003, Kevin Brosius wrote:
> >
> > > I've noticed the following xmag segv with current CVS when trying to
> > > view part of the background in the development version of e (e17). Is
> > > this an xmag or a window manager problem? (Or both?)
> > >
> > >
> > > (gdb) r
> > > X Error of failed request: BadMatch (invalid parameter attributes)
> > > Major opcode of failed request: 73 (X_GetImage)
> > > Serial number of failed request: 668
> > > Current serial number in output stream: 668
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x0804afbf in GetMinIntensity ()
> > >
> > > This only occurs when the start point of the xmag selection window is
> > > over the background. Clicking inside an application works fine, as does
> > > clicking inside but near an application edge which shows both
> > > application and background image magnification. (I can magnify the
> > > background as long as the click doesn't occur on it.)
> > >
> > > --
> > > Kevin
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: ATI cursor bug in cvs?
Marc Aurele La France wrote: > > > On Sat, 22 Feb 2003, Kevin Brosius wrote: > > > XFree86 Version 4.2.99.902 (4.3.0 RC 2) > > Release Date: 20 February 2003 > > > I notice that their appears to be a cursor drawing bug during a mode > > switch. If I use Ctr-Alt-+-, immediately after the switch the upper > > left corner of the screen is inverse colored, almost like the swcursor > > image was loaded from that corner, then overlayed on it again, but > > without full color support. The discoloration is not captured in a > > screen shot. > > > Hardware is > > (--) PCI:*(0:14:0) ATI Technologies Inc Rage XL rev 39, Mem @ > > 0xf500/24, 0xf > > 4003000/12, I/O @ 0x1800/8 > > > driver info: > > (II) Module mouse: vendor="The XFree86 Project" > > compiled for 4.2.99.902, module version = 1.0.0 > > Module class: XFree86 XInput Driver > > ABI class: XFree86 XInput driver, version 0.4 > > (II) ATI: ATI driver (version 6.4.18) for chipsets: ati, ativga > > > (II) Primary Device is: PCI 00:0e:0 > > (II) ATI: Candidate "Device" section "Device[0]". > > (II) ATI: Shared PCI/AGP Mach64 in slot 0:14:0 detected. > > > (II) Setting vga for screen 0. > > (==) ATI(0): Chipset: "ati". > > (**) ATI(0): Depth 16, (--) framebuffer bpp 16 > > I've committed a change to fix this problem. Yes, that's perfect, no more problem here. Thanks! -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
xmag segv's
I've noticed the following xmag segv with current CVS when trying to view part of the background in the development version of e (e17). Is this an xmag or a window manager problem? (Or both?) (gdb) r X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 73 (X_GetImage) Serial number of failed request: 668 Current serial number in output stream: 668 Program received signal SIGSEGV, Segmentation fault. 0x0804afbf in GetMinIntensity () This only occurs when the start point of the xmag selection window is over the background. Clicking inside an application works fine, as does clicking inside but near an application edge which shows both application and background image magnification. (I can magnify the background as long as the click doesn't occur on it.) -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
ATI cursor bug in cvs?
With CVS from yesterday: XFree86 Version 4.2.99.902 (4.3.0 RC 2) Release Date: 20 February 2003 I notice that their appears to be a cursor drawing bug during a mode switch. If I use Ctr-Alt-+-, immediately after the switch the upper left corner of the screen is inverse colored, almost like the swcursor image was loaded from that corner, then overlayed on it again, but without full color support. The discoloration is not captured in a screen shot. Hardware is (--) PCI:*(0:14:0) ATI Technologies Inc Rage XL rev 39, Mem @ 0xf500/24, 0xf 4003000/12, I/O @ 0x1800/8 driver info: (II) Module mouse: vendor="The XFree86 Project" compiled for 4.2.99.902, module version = 1.0.0 Module class: XFree86 XInput Driver ABI class: XFree86 XInput driver, version 0.4 (II) ATI: ATI driver (version 6.4.18) for chipsets: ati, ativga (II) Primary Device is: PCI 00:0e:0 (II) ATI: Candidate "Device" section "Device[0]". (II) ATI: Shared PCI/AGP Mach64 in slot 0:14:0 detected. (II) Setting vga for screen 0. (==) ATI(0): Chipset: "ati". (**) ATI(0): Depth 16, (--) framebuffer bpp 16 -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
Alan Hourihane wrote: > > > Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything > to add to this, please send it in. I'd suggest the following s3virge driver note: Doublescan modes (320x200) are supported and tested in depth 8 and 16 on DX, but disable XVideo. Doublescan modes on other chipsets are untested. (From patch #5617) -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XCursor and remote apps?
Keith Packard wrote: > > > Around 19 o'clock on Feb 9, Kevin Brosius wrote: > > > Is it expected that remote apps will use the theme setup on their host, > > rather than the one on the server side? Here's why I ask: > > Depends on how things are configured. Xcursor themes can be configured > through an env variable (XCURSOR_THEME), an X resource (Xcursor.theme) or > through the index.theme file for the default theme. If you configure the > theme via the X resource, then all X apps on your screen will use the same > theme name. Of course, as the themes are loaded from the applications name > space, the actual theme or cursor might be different, depending on the > contents of the file system. Hmm. So, in my case, I have a custom theme on the localhost (setup in .Xresources and installed in $HOME/.icons.). When the remote app runs, it looks for that theme, and failing to find it uses the default theme on the remote filesystem, right? (Which is redglass in this case.) Why don't all the cursors for the remote applications use redglass? The standard pointer seems fine in Netscape, but the menu pointer is redglass. xterm displays the redglass text bar. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XCursor and remote apps?
Is it expected that remote apps will use the theme setup on their host, rather than the one on the server side? Here's why I ask: Running 4.2.99.901 with whiteglass or a theme I'm making up works fine for local applications. Now I remote log into a machine running 4.2.99.4 (which defaults to redglass?) and startup Netscape. When I use the remote app, some cursors use redglass while some use the local cursors. xterm behaves the same way, displaying the redglass cursor if run from the remote host. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xcursor.h path in 4.2.99.4?
It seems that Xcursor.h is installed in /usr/include/X11/Xcursor/Xcursor.h in 4.2.99.4. Is this intentional? Why isn't it directly in X11? -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What happened to CVSWeb?
Mark Vojkovich wrote: > > >It's not there anymore. > > Mark. Seems to be there now, temporary problem? http://cvsweb.xfree86.org/cvsweb/ -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.2.99.4 Test report: ATI Rage XL accel bug?
Marc Aurele La France wrote: > > > On Wed, 29 Jan 2003, Kevin Brosius wrote: > > > > > Is there a known problem with accelerated fills on some ATI cards at > > > > depth 24? Using an ATI Rage XL (depth 16 log available at > > > > http://kevb.net/files/XFree86_ATI_16.log) at depth 24, I notice > > > > corrupted fill backgrounds on the text in xf86cfg. To reproduce, start > > > > xf86cfg, open Expert mode (clicking on the upper right text box) and > > > > then open up some of the config file field text boxes. Patterned fill > > > > space behind the text is garbage on my card (stipple problem?) I'm > > > > unable to capture a shot of the window of xf86cfg for some reason, both > > > > xv and scrot either will not capture, or capture only background behind > > > > this app, so I can't illustrate the problem. > > > > > Option "noaccel" solves the problem, as does running at depth 16. Depth > > > > 24 log available on request. > > > > I assume you mean depth 24/32? If so, does the problem show in 24/24? > > > The default, which I see is 24/32. I've also seen it happen at depth 16 > > now, but not so far at 24/24 in about a half dozen trials. > > > Interestly, in depth 16 if I switch away from the server and back again, > > forcing a redraw, that sometimes fixes the pattern. > > > Depth 24/24 log at http://kevb.net/files/XFree86_ati_24_24.log > > 24/32 log at http://kevb.net/files/XFree86_nokill_nomouse.log > > Could you narrow this down to the XAA primitive causing the problem? The > driver currently accelerates screen-to-screen copies, solid fills, 8x8 > mono pattern fills, scanline CPU-to-screen colour expansion and (other > than for 24bpp) solid lines. > > Thanks. > > Marc. Screen-to-screen it appears. Problem is not reproducible when I see: (II) ATI(0): Using XFree86 Acceleration Architecture (XAA) Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Setting up tile and stipple cache: 9 128x46 slots after setting "XaaNoScreenToScreenCopy", and just setting "XaaNoOffscreenPixmaps" is not enough to fix it for me. Testing was done on depth 24/32. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: s3virge & bigendian
Meelis Roos wrote: > > > > Do you know what physical memory the card has without looking at > > xfree86? ViRGE cards can be 2M or 4M. You might try specifying 2M and > > I googled a little and found that it's likely to be a 2M card. The card > is Formac GA6 (Formac Pro Media 20 Plus), it contains 4 RAM chips and 4 > places for additional chips. The chips are labeled V53C16258HK40. On > Formac Pro Media 40 Plus there are 8 such RAM chips and total 4M of RAM. > > Some more Googling and now it's sure - there are 4 chips of (256Kx16) so > 2M total. > > I tried the card in x86 to see if the RAM size is detected right there > but I had little success. First the PC didn't like F-COde ROM so the > card could not be used as the primary card. Running atimach64 as primary > and s3virge as secondary didn't work either - both wanted to decode VGA > addresses and some chars appeared on screen but some in the video ram of > the other card. Finally it booted up using s3virge dx as primary and > this (effectively biosless) s3virge as secondary. But I have big trouble > running X - I configured XF 4.2.1 for this card but it tends to hang on > DDC, Accel etc. I couldn't squeeze the guessed videoram size out of it > so I don't know whether X detects the right videoram size on x86. > > > see if that resolves this issue. Of course you will only be able to run > > modes that fit in 2M, but that will fix the possibility of pixmap cache > > Will try in the evening (GMT+0200 here). How am I suppsed to force > videoram size - no option for that? OK, will just hardcode it and see. Some options that are general to all drivers are only documented in 'man XF86Config' not 'man s3virge'. You should find that 'videoram 2048' works for the s3virge driver in the Device section. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: s3virge & bigendian
Meelis Roos wrote: > > > > > Now the remanining problem is the garbage in lower part of the screen - > > > any ideas about that? It's there even with NoAccel and changing too. > > > > If you have accel enabled, but then use 'sw_cursor' option, does the > > noise still appear? > > Yes. Just moving the cursor makes it flicker. > > The flickering part is the last 0.5 M of the framebuffer. 2M is OK and > the last 0.5M is garbage (at 1280x1024,16bpp). Something to do with > video ram size detection? > > Haven't still had time to test this specific card in x86. Do you know what physical memory the card has without looking at xfree86? ViRGE cards can be 2M or 4M. You might try specifying 2M and see if that resolves this issue. Of course you will only be able to run modes that fit in 2M, but that will fix the possibility of pixmap cache being a problem, as it won't create any pixmap cache if there is no room for it after the framebuffer. So, first thing to make sure is that we are finding the correct amount of video memory. And in another message I said: > Michel Dänzer wrote: > > > > > > On Mon, 2003-01-20 at 18:57, Meelis Roos wrote: > > > > > > Colors are OK now but the bitmaps are broken. When fonts are drawn in > > > xterm, every 8 pixels are horizontally reversed (in 16bpp mode). Mozilla > > > window contets are mostly OK but some garbage remains inside frames. > > > When moving xterm over mozilla, traces remain (probably the same bitmap > > > reversion problem). > > > > Have you tried setting BIT_ORDER_IN_BYTE_LSBFIRST or > > BIT_ORDER_IN_BYTE_MSBFIRST in the *ColorExpandFillFlags field of the > > XAAInfoRec ? > > > > > is fbOffset the right field to use the 32M offset that bigendian mode > > > needs? > > > > No, I think you should leave fbOffset at 0 and add the 32M to the > > pScrn->memPhysBase (and pass that to xf86MapPciMem) instead. > > The virge supports a seperate config for little/bigendian memory > mapping, so this might be a better choice than adding 32M as you > suggest. That was bad advice :( Michel is correct. The ViRGE supports bigendian addressing in the upper 32M of a 64M window from it's base address. I'd suggest adding an offset of 32M for each allocation of each of the following mapped variables in S3VMapMem(): MapBase, MapBaseDense, FBBase The ViRGE manual says the following: "For big endian addressing, add 2 to the most significant hex digit shown in Table 15-1, i.e., 0xx becomes 2xx and 1xx becomes 3xx . Thus the total address space decoded by ViRGE is 64 MBytes." Table 15-1 is a Little endian addressing table, of the form: DescOffset from base (hex) Linear Addressing (16M) 000 - 0FF Image Data Transfer (32K) 100 - 100 7FFF PCI Conf space registers100 8000 - 100 8043 ... Local Per Bus Registers 100 FF00 - 100 FF5C Sorry for the confusion, -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.2.99.4 Test report: ATI Rage XL accel bug?
Marc Aurele La France wrote: > > > On Wed, 29 Jan 2003, Kevin Brosius wrote: > > > Is there a known problem with accelerated fills on some ATI cards at > > depth 24? Using an ATI Rage XL (depth 16 log available at > > http://kevb.net/files/XFree86_ATI_16.log) at depth 24, I notice > > corrupted fill backgrounds on the text in xf86cfg. To reproduce, start > > xf86cfg, open Expert mode (clicking on the upper right text box) and > > then open up some of the config file field text boxes. Patterned fill > > space behind the text is garbage on my card (stipple problem?) I'm > > unable to capture a shot of the window of xf86cfg for some reason, both > > xv and scrot either will not capture, or capture only background behind > > this app, so I can't illustrate the problem. > > > Option "noaccel" solves the problem, as does running at depth 16. Depth > > 24 log available on request. > > I assume you mean depth 24/32? If so, does the problem show in 24/24? The default, which I see is 24/32. I've also seen it happen at depth 16 now, but not so far at 24/24 in about a half dozen trials. Interestly, in depth 16 if I switch away from the server and back again, forcing a redraw, that sometimes fixes the pattern. Depth 24/24 log at http://kevb.net/files/XFree86_ati_24_24.log 24/32 log at http://kevb.net/files/XFree86_nokill_nomouse.log -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XVideo - adding and removing interfaces?
David Dawes wrote:
>
>
> On Mon, Jan 27, 2003 at 09:52:48PM -0500, Kevin Brosius wrote:
> >I'd like to be able to add/remove an XVideo interface on the fly during
> >mode switches. Is this possible with the existing interface? I don't
> >see anything in the DESIGN doc other than the xf86XVScreenInit()
> >function for setup. The ViRGE doesn't seem capable of XVideo during
> >doublescan modes (320x200), so I'd like to be able to remove the Xv
> >interfaces when in those modes, then re-add them when a compatible mode
> >is switched back in.
>
> I did something similar to this in the i810 driver (the i830 part)
> because there are bandwidth limits for the video overlay on those chips,
> and using the overlay when those limits are exceeded results in a lockup.
> See the SwitchMode{Before,After} bits in i830_video.c and i830_driver.c.
> There are some problems with this quick implementation that I need to
> fix, but it does acheive my main goal of avoiding lockups by using Xv
> in modes where it will cause a lockup.
Yeah, I realized about 10 minutes after sending the mail that removing
the interfaces was a problem, because clients might persist through a
mode switch. I submitted a virge patch that just ignores the overlay
commands when the mode isn't overlay capable. I'll take a look at your
method also. Thanks,
--
Kevin
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
4.2.99.4 Test report: ATI Rage XL accel bug?
Is there a known problem with accelerated fills on some ATI cards at depth 24? Using an ATI Rage XL (depth 16 log available at http://kevb.net/files/XFree86_ATI_16.log) at depth 24, I notice corrupted fill backgrounds on the text in xf86cfg. To reproduce, start xf86cfg, open Expert mode (clicking on the upper right text box) and then open up some of the config file field text boxes. Patterned fill space behind the text is garbage on my card (stipple problem?) I'm unable to capture a shot of the window of xf86cfg for some reason, both xv and scrot either will not capture, or capture only background behind this app, so I can't illustrate the problem. Option "noaccel" solves the problem, as does running at depth 16. Depth 24 log available on request. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
ViRGE 320x240 patch / test driver available
I've put up an updated test driver with new 320x200 and doublescan mode support at http://www.user1.netcarrier.com/~kbrosius/pages/virge.html . Please report any problems here on the mailing list. Thanks to "linuzappz" <[EMAIL PROTECTED]> and Eugene Grosbein <[EMAIL PROTECTED]> for pointing out this needed to be fixed and various testing. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XVideo - adding and removing interfaces?
I'd like to be able to add/remove an XVideo interface on the fly during mode switches. Is this possible with the existing interface? I don't see anything in the DESIGN doc other than the xf86XVScreenInit() function for setup. The ViRGE doesn't seem capable of XVideo during doublescan modes (320x200), so I'd like to be able to remove the Xv interfaces when in those modes, then re-add them when a compatible mode is switched back in. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.2.99.4 Test report : Ctr-Alt-BkSpc status?
David Dawes wrote: > > > On Sun, Jan 26, 2003 at 03:06:36AM -0500, Kevin Brosius wrote: > > >> Does the server work correctly other than the key sequence not > >> working? If it is stuck somewhere, it might explain both why > >> SIGTERM and SIGHUP didn't do anything and why the terminate key > >> sequence didn't work. > > > >Yes, the server seems to work fine, other than ignoring Ctl-Alt-BkSpc. > >Other Alt sequences work, like Ctl-Alt-+. > > Those other sequences are handled in the same way as Ctl-Alt-BkSpc, > so it does point to the mapping for that one getting overriden after > the X server starts. > > >> Could you send the 'xmodmap -pk' output? Are you running any > >> xmodmap script as part of your startx/xdm rc files that might be > >> re-mapping the BackSpace key? > > > >The patch doesn't seem to make a difference. > > > >I've attached xmodmap -pk. > > The only difference I see between yours and mine is that mine has the > following for the backspace key: > > 22 0xff08 (BackSpace) 0xfed5 (Terminate_Server) > > while yours is: > > 22 0xff08 (BackSpace) > > >xmodmap scripts, that may be it. It looks like SuSE uses a .xinitrc > >which may call 'xmodmap /usr/X11R6/lib/X11/Xmodmap' if it exists and > >XSESSION_IS_UP is set. Although it comments that XSESSION_IS_UP is set > >by xdm, which I am not running. If it where set, it would use an old > >Xmodmap, as I've changed ProjectRoot on this machine and that default > >path is an older version, 4.1.0. > > > >Other than that, I don't see anything calling xmodmap. And I don't > >think it's calling that one, since it's xdm related. > > A way to double-check this is to run something like: > > startx /path/to/your/twm > > or just: 'XFree86' > > and see if the server terminate sequence works then. Yes, this case works. So, something in my setup (an xmodmap call I haven't located yet?) is incompatible with the recent changes? When started this way, running xmodmap -pk against the server does show: 22 0xff08 (BackSpace) 0xfed5 (Terminate_Server) -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.2.99.4 Test report : Ctr-Alt-BkSpc status?
David Dawes wrote: > > > On Sat, Jan 25, 2003 at 04:01:02PM -0500, Kevin Brosius wrote: > >David Dawes wrote: > >> > >> > >> On Sat, Jan 25, 2003 at 02:42:57PM -0500, Kevin Brosius wrote: > >> >I've upgraded a machine from an early version of 4.2.99 (.1 I think) and > >> >find a couple problems. I am unable to kill the server with > >> >Ctr-Alt-BkSpc as mentioned in several earlier list emails, although this > >> >problem is listed as resolved. Are there changes required in XF86Config > >> >or elsewhere to make this work? I expected XF86Config would be > >> >compatible with earlier versions of 4.2.99.x. > >> > >> It should still work with that keyboard config, and it does for me. > >> There have been some changes to allow the key sequences like this to be > >> redefined via XKB, but Joe added code recently to automatically fall > >> back to the built-in sequences when they're not defined in the XKB maps. > >> None of that should be a problem for a complete 4.2.99.4 installation. > >> > >> I noticed that your log file was also for the mouse auto-detect problem > >> you reported in a separate message. Have you confirmed that the two > >> things are not related (I don't see how they should be, but it's worth > >> checking if you haven't already)? > >> > > > >After changing the mouse protocol, the mouse works, but the server still > >cannot be killed with Ctr-Alt-BkSpc. I seem to have caught the more > >painful bugs, as I was unable to kill the server without a reboot (no > >keyboard sequence response and no mouse exit.) > > > >I thought the core server would terminate on a kill -SIGTERM or restart > >with kill -SUGHUP, but it ignored both of these. It was removed with a > >SIGKILL, however it did not go through the driver shutdown sequence, > >leaving the console unusable. > > Those signals should work as you describe, but I often find 'kill > -SEGV' useful to kill the server cleanly when it's "stuck" somewhere :-). > > Does the server work correctly other than the key sequence not > working? If it is stuck somewhere, it might explain both why > SIGTERM and SIGHUP didn't do anything and why the terminate key > sequence didn't work. Yes, the server seems to work fine, other than ignoring Ctl-Alt-BkSpc. Other Alt sequences work, like Ctl-Alt-+. > > >> >Here are relevant sections of XF86Config: > >> > > >> >Section "ServerLayout" > >> >Identifier "XFree86 Configured" > >> >Screen 0 "Screen0" 0 0 > >> >InputDevice"Mouse0" "CorePointer" > >> >InputDevice"Keyboard0" "CoreKeyboard" > >> >EndSection > >> > > >> >Section "InputDevice" > >> >Identifier "Keyboard0" > >> >Driver "keyboard" > >> >EndSection > >> > >> Try adding the following to your ServerLayout section: > >> > >> Option "HandleSpecialKeys" "Always" > >> > >> and see if that makes a difference. If it does, we'll need to track > >> down why either the XKB map isn't working or it's not falling back > >> correctly to the built-in settings. > > > >This option works, and Ctr-Alt-BkSpc shuts down the server as expected > >with it. > > OK, that's useful information. > > While checking, I found a problem that would show up when building > with XKB disabled, but that included a build failure. Here's a patch > that fixes that, but I don't know if it'll make any difference to > what you're seeing. > > Could you send the 'xmodmap -pk' output? Are you running any > xmodmap script as part of your startx/xdm rc files that might be > re-mapping the BackSpace key? The patch doesn't seem to make a difference. I've attached xmodmap -pk. xmodmap scripts, that may be it. It looks like SuSE uses a .xinitrc which may call 'xmodmap /usr/X11R6/lib/X11/Xmodmap' if it exists and XSESSION_IS_UP is set. Although it comments that XSESSION_IS_UP is set by xdm, which I am not running. If it where set, it would use an old Xmodmap, as I've changed ProjectRoot on this machine and that default path is an older version, 4.1.0. Other than that, I don't see anything calling xmodmap. And I don't think it's calling that one, since it&#x
Re: 4.2.99.4 Test report: Mouse protocol auto fails
David Dawes wrote: > > > On Sat, Jan 25, 2003 at 03:21:10PM -0500, Kevin Brosius wrote: > >For a previously working setup, mouse protocol auto no longer succeeds > >in configuring the mouse, however it appears not to fail either, leaving > >the server up with a non-working mouse pointer. I do not have > >'AllowMouseOpenFail' set. > > Could you try the attached patch, and let me know what happens. The > 2nd hunk is the important one, and the problem there resulting on only > the first character of the PnP ID string being read. Yes, that fixes it. Full pnp info is now printed in the log also (but twice, why is that?) (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) Mouse0: PnP ID string: `(!DLGI8049\\MOUSE\PNP0F0890)' (II) Mouse0: PnP rev 1.00 (II) Mouse0: PnP-detected protocol ID: 4 (II) Mouse0: PnP ID string: `(!DLGI8049\\MOUSE\PNP0F0890)' (II) Mouse0: PnP rev 1.00 (II) Mouse0: PnP-detected protocol ID: 4 (--) Mouse0: PnP-detected protocol: "MouseMan" -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.2.99.4 Test report : Ctr-Alt-BkSpc status?
David Dawes wrote: > > > On Sat, Jan 25, 2003 at 02:42:57PM -0500, Kevin Brosius wrote: > >I've upgraded a machine from an early version of 4.2.99 (.1 I think) and > >find a couple problems. I am unable to kill the server with > >Ctr-Alt-BkSpc as mentioned in several earlier list emails, although this > >problem is listed as resolved. Are there changes required in XF86Config > >or elsewhere to make this work? I expected XF86Config would be > >compatible with earlier versions of 4.2.99.x. > > It should still work with that keyboard config, and it does for me. > There have been some changes to allow the key sequences like this to be > redefined via XKB, but Joe added code recently to automatically fall > back to the built-in sequences when they're not defined in the XKB maps. > None of that should be a problem for a complete 4.2.99.4 installation. > > I noticed that your log file was also for the mouse auto-detect problem > you reported in a separate message. Have you confirmed that the two > things are not related (I don't see how they should be, but it's worth > checking if you haven't already)? > After changing the mouse protocol, the mouse works, but the server still cannot be killed with Ctr-Alt-BkSpc. I seem to have caught the more painful bugs, as I was unable to kill the server without a reboot (no keyboard sequence response and no mouse exit.) I thought the core server would terminate on a kill -SIGTERM or restart with kill -SUGHUP, but it ignored both of these. It was removed with a SIGKILL, however it did not go through the driver shutdown sequence, leaving the console unusable. > >Here are relevant sections of XF86Config: > > > >Section "ServerLayout" > >Identifier "XFree86 Configured" > >Screen 0 "Screen0" 0 0 > >InputDevice"Mouse0" "CorePointer" > >InputDevice"Keyboard0" "CoreKeyboard" > >EndSection > > > >Section "InputDevice" > >Identifier "Keyboard0" > >Driver "keyboard" > >EndSection > > Try adding the following to your ServerLayout section: > > Option "HandleSpecialKeys" "Always" > > and see if that makes a difference. If it does, we'll need to track > down why either the XKB map isn't working or it's not falling back > correctly to the built-in settings. This option works, and Ctr-Alt-BkSpc shuts down the server as expected with it. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
4.2.99.4 Test report: Mouse protocol auto fails
For a previously working setup, mouse protocol auto no longer succeeds in configuring the mouse, however it appears not to fail either, leaving the server up with a non-working mouse pointer. I do not have 'AllowMouseOpenFail' set. Log file: http://kevb.net/files/XFree86_nokill_nomouse.log This is a serial Logitech Trackman Marble FX. If I specify protocol 'mouseman' the device works ok. I previously used the 'mouseman' protocol before 'auto' was made to work (a year or two ago.) The working log info for the device is: (**) Option "Protocol" "mouseman" (**) Mouse0: Protocol: "mouseman" (**) Option "CorePointer" (**) Mouse0: Core Pointer (**) Option "Device" "/dev/mouse" (**) Option "BaudRate" "1200" (**) Option "StopBits" "1" (**) Option "DataBits" "7" (**) Option "Parity" "None" (**) Option "Vmin" "1" (**) Option "Vtime" "0" (**) Option "FlowControl" "None" (**) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (==) Mouse0: Buttons: 3 (**) Mouse0: BaudRate: 1200 -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
4.2.99.4 Test report : Ctr-Alt-BkSpc status?
I've upgraded a machine from an early version of 4.2.99 (.1 I think) and find a couple problems. I am unable to kill the server with Ctr-Alt-BkSpc as mentioned in several earlier list emails, although this problem is listed as resolved. Are there changes required in XF86Config or elsewhere to make this work? I expected XF86Config would be compatible with earlier versions of 4.2.99.x. Here are relevant sections of XF86Config: Section "ServerLayout" Identifier "XFree86 Configured" Screen 0 "Screen0" 0 0 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" EndSection Will this no longer be sufficient to get the old behavior? Log file: http://kevb.net/files/XFree86_nokill_nomouse.log -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: s3virge & bigendian
Michel Dänzer wrote: > > > On Mon, 2003-01-20 at 18:57, Meelis Roos wrote: > > > > Colors are OK now but the bitmaps are broken. When fonts are drawn in > > xterm, every 8 pixels are horizontally reversed (in 16bpp mode). Mozilla > > window contets are mostly OK but some garbage remains inside frames. > > When moving xterm over mozilla, traces remain (probably the same bitmap > > reversion problem). > > Have you tried setting BIT_ORDER_IN_BYTE_LSBFIRST or > BIT_ORDER_IN_BYTE_MSBFIRST in the *ColorExpandFillFlags field of the > XAAInfoRec ? > > > is fbOffset the right field to use the 32M offset that bigendian mode > > needs? > > No, I think you should leave fbOffset at 0 and add the 32M to the > pScrn->memPhysBase (and pass that to xf86MapPciMem) instead. The virge supports a seperate config for little/bigendian memory mapping, so this might be a better choice than adding 32M as you suggest. -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: s3virge & bigendian
Meelis Roos wrote: > > > > Have you tried setting BIT_ORDER_IN_BYTE_LSBFIRST or > > BIT_ORDER_IN_BYTE_MSBFIRST in the *ColorExpandFillFlags field of the > > XAAInfoRec ? > > Wow. Option NoAccel makes the reversion go away and fixes garbage in > Mozilla too. > > Changing MSBFIRST to LSBFIRST fixed the fonts, thanks! > > Garbage in Mozilla still remains when acceleration is turned on - what > other XAA bits should I look over? > > Now the remanining problem is the garbage in lower part of the screen - > any ideas about that? It's there even with NoAccel and changing too. If you have accel enabled, but then use 'sw_cursor' option, does the noise still appear? -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
