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: 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: 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: 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
[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 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; incolors; 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
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; incolors; 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
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: 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
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: 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: 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
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: 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
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: 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 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 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
