Re: (patch seq: 6202) XFree86-4.4.0 -- IPv6 support causes serious problems
Redirected to devel@ On Sun, 7 Mar 2004, Peter Breitenlohner wrote: > Dear XFree86 maintainers, > I fully understand that XFree86 has to support IPv6. The current > implementation has, however, a serious flaw: when compiled with IPv6 support > (which is the default for most linux/gnu systems) the progams implicitly > assume that IPv6 is supported by the kernel. In our case that is not so, and > in order to get things working I had to > #define BuildIPv6 NO > in xc/config/cf/host.def, thereby permanantly disabling IPv6 support. > It would be extremely helpful if one could compile XFree86 with IPv6 > support, but then disable IPv6 at runtime via configuration files > (resources) and/or command line options (in order to avoid various > timeouts), and the programs should automatically fall back to IPv4 in case > IPv6 is not supported by the kernel. > The actual problems encountered were twofold: > 1. xdm produced an error message > chooser socket creation failed > and there was just a useless parent process but no child process(es) and no > Xserver was started. I think the lines 69ff in xc/programs/xdm/socket.c > #if defined(IPv6) && defined(AF_INET6) > chooserFd = socket (AF_INET6, SOCK_STREAM, 0); > #else > chooserFd = socket (AF_INET, SOCK_STREAM, 0); > #endif > ought to be > #if defined(IPv6) && defined(AF_INET6) > chooserFd = socket (AF_INET6, SOCK_STREAM, 0); > if (chooserFd == -1) > #endif > chooserFd = socket (AF_INET, SOCK_STREAM, 0); > although I haven't tested this. > 2. Trying to start chooser by hand lead to a segmentation fault! With a > little tracing I found the following code in xc/programs/xdm/chooser.c in > lines 844ff > #if defined(IPv6) && defined(AF_INET6) > socket6FD = socket (AF_INET6, SOCK_DGRAM, 0); > #endif > and later in lines 856ff > XtAddInput (socketFD, (XtPointer) XtInputReadMask, ReceivePacket, > (XtPointer) &socketFD); > #if defined(IPv6) && defined(AF_INET6) > XtAddInput (socket6FD, (XtPointer) XtInputReadMask, ReceivePacket, > (XtPointer) &socket6FD); > #endif > The second code fragment certainly ought to be > XtAddInput (socketFD, (XtPointer) XtInputReadMask, ReceivePacket, > (XtPointer) &socketFD); > #if defined(IPv6) && defined(AF_INET6) > if (socket6FD != -1) > XtAddInput (socket6FD, (XtPointer) XtInputReadMask, ReceivePacket, > (XtPointer) &socket6FD); > #endif > but that may not suffice. Calling XtAddInput with a untested first argument > is just asking for serious trouble. Please check if your changes actually fix the problem. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 fill problems
I've got a Thinkpad T40 running Fedora Core 1 (XFree86-4.3.0-42) and the
VESA framebuffer (not sure that matters). When I run the attached
simple program, I get problems with the fills when using Stipples. The
whole object in question isn't filled properly if it hangs off the left
edge of the window.
Running this on my RH9 box (XFree86-4.3.0-2) works fine. When run on
RH9 but displaying on my laptop, it's broke.
I don't know if this is an XF86 bug, a packaging bug, or what else? See
attached code. I've got pictures, but they're about 700K combined, I
didn't want to spam the list(s) unless someone wants to see my output.
The odd thing I noticed just now is that if I move the window, the fill
pattern gets better, as if the root window dimensions are somehow
involved in whether the fill is processed properly. If I move the
window far enough toward the center of the screen so that the objects
would fit on the root window (ignoring the app window boundaries), then
things work fine.
It also displays fine if I use solid fills.
Even odder is that it works if there is another window on top. I
discovered this with the Gimp acquire tear-off menu, but it works as
well with gnome-terminal.
Can someone enlighten me? This seems to be a serious issue.
Regards,
Carl
//**BEGINDOC
//
// Copyright (c) 1998, 1999Spatial Software Solutions, Inc.
//
// Library: OutputDevice
//
// Class: X11OutputDevice
//Test program for X11OutputDevice
//
// $RCSfile: test5.cxx,v $ $Revision: 1.1.2.1 $ $Date: 2004/03/05 21:41:13 $
//
//ENDDOC
// Flags
// Includes
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
// Imports
// Exports
// Constants
// Local Classes
// Local Variables
Widget Ggraf;
Display* dpy = NULL;
Window win;
GC gc;
// Forward Declarators
// Static Class Members
// Code
GC CreateGC(Display* dsp, Window win)
{
int screen = DefaultScreen(dsp);
XGCValues values;
values.function = GXcopy;
values.plane_mask = AllPlanes;
values.line_width = 0;
values.line_style = LineSolid;
values.cap_style = CapButt;
values.fill_style = FillSolid;
values.join_style = JoinBevel;
values.subwindow_mode = ClipByChildren;
values.graphics_exposures = False;
values.clip_x_origin = 0;
values.clip_y_origin = 0;
values.clip_mask = None;
values.foreground = WhitePixel(dsp, screen);
values.background = BlackPixel(dsp, screen);
values.join_style = JoinRound;
GC gc = XCreateGC(dsp, win,
GCFunction|GCPlaneMask|GCLineWidth|
GCLineStyle|GCCapStyle|
GCFillStyle|GCJoinStyle|GCForeground|
GCBackground|GCSubwindowMode|
GCGraphicsExposures|GCClipXOrigin|
GCClipYOrigin|GCClipMask,
&values);
if (gc == None) {
printf("Unable to get GC\n");
exit(-1);
}
return gc;
}
void SetFillStipple(Display* dsp, Window win, GC gc)
{
unsigned char opaque_bits[] = {
0x55, 0x50, 0xa0, 0xaa, 0x50, 0x55, 0xaa, 0xa0, 0x55, 0x50, 0xaa, 0xa0,
0x55, 0x50, 0xa0, 0xaa, 0x50, 0x55, 0xaa, 0xa0, 0x55, 0x50, 0xaa, 0xa0,
0x55, 0x50, 0xa0, 0xaa, 0x50, 0x55, 0xaa, 0xaa};
Pixmap fillPix = XCreatePixmapFromBitmapData(dsp, win,
(char *)opaque_bits,
16, 16,
1, 0, 1);
printf("Setting fill pixmap\n");
XSetFillStyle(dsp, gc, FillStippled);
XSetStipple(dsp, gc, fillPix);
XFreePixmap(dsp, fillPix);
}
void Clear(Display* dsp, Window win, GC gc)
{
#if CLEAR
printf("Clearing Window\n");
XClearWindow(dsp, win);
#else
XSetFillStyle(dsp, gc, FillSolid);
XSetForeground(dsp, gc, 0xff);
XFillRectangle(dsp, win, gc, 0, 0, 800, 800);
#endif
}
void DrawRectangle(Display* dsp, Window win, GC gc)
{
printf("Set foreground\n");
XSetForeground(dsp, gc, 0x00ff00);
XSetBackground(dsp, gc, 0xff);
printf("Allocating
Re: Console Switching broke on NetBSD with XFree86 4.4.0
On Sun, Mar 07, 2004 at 08:01:10PM +0100, Matthieu Herrb wrote: > Yes. Several OpenBSD users found that too. The attached diff fixes it. Yes, it does. Thank you very much. Kind regards -- Matthias Scheler http://scheler.de/~matthias/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
On Sun, 7 Mar 2004, James Wright wrote: >We are concentrating on developing games which utilise polished 2d graphics > engines, > rather than 3d. I know it sounds crazy but its what we want to do... > >With most 2d engines the number of pixels drawn is usually kept to a minimum, > unless > there is a huge amount of overdraw going on, then its nearly always faster to draw > direct to the framebuffer. If we do need to scroll the whole screen, then we would > try > to alter start of viewport address rather than transferring the entire screen. > >I'm just concerned that the DGA extension will be removed with no adequete > replacement. > The main issue with DGA seems to be the way it requires root privs and can write to > other parts of memory. Can we not have some sort of "/dev/dga" device or is this not > the place to ask ;) is this not feasible? > > > James I think the biggest problem with DGA is that driver writers don't want to support it. I don't even test it anymore. If it didn't work, I wouldn't know about it until somebody complained. The DGA mode complicates what the driver has to do. We're trying to focus on how we use the offscreen memory for graphics command buffers, pixmaps, textures and video overlays, and don't like to have to deal with a mode where we have to make concessions for some app that wants to scribble on the framebuffer itself. As far as I'm concerned, there are alternatives. You can render to an XImage and use ShmPutImage, or if you need vblank syncing you can use OpenGL. Apps having direct framebuffer access is something that I would consider to be a legacy feature. The natural tendency is to drop support for that sort of thing eventually. Besides, I'm not sure we can guarantee that future hardware is going to be very amenable to direct framebuffer access. I've seen some evidence suggesting that it's not. Mark. > > > > On Sat, 6 Mar 2004 19:02:00 -0800 (PST) > Mark Vojkovich <[EMAIL PROTECTED]> wrote: > > >I expect it will go away eventually. It's still the case for > > most access patterns that rendering in system memory and then > > copying the result to the framebuffer is faster than CPU rendering > > directly to the framebuffer. Only the most simple game engines (write- > > only SW scanline renderers) can benefit from direct framebuffer access. > > Why aren't you using OpenGL? > > > > Mark. > > > > On Sun, 7 Mar 2004, James Wright wrote: > > > > > Hello, > > > > > >Apologies if this is the incorrect list to post to but i couldn't decide > > > between the general "forum" > > > list or this one. My question concerns the DGA extension in XFree86, whether it > > > will be removed from > > > future versions, and the alternatives. We are currently in the process of > > > developing games for the > > > Linux OS. We require direct access to the video framebuffer, the ability to > > > change resolution, refresh > > > rate, indexed palettes, and the ability to alter the start screen position > > > pointer (for hardware > > > scrolling). At first we wrote our 2D drawing libs to use SVGALib, but after > > > numerous problems with memory > > > leaks and bad support for many gfx cards we switched to X11->DGAv2. We are > > > reasonably happy with DGA as > > > it stands, with the only annoyance being that it requires root privs. I have > > > seen it mentioned that > > > DGA could be removed in future XFree86 releases, is this true? If so, what are > > > the alternatives for us > > > to use? It is obvious that there are alot of apps out there that really can't > > > justify the use of DGA, > > > but I feel that this application (games) really can benefit from using it. Any > > > extra layers between > > > our drawing and the framebuffer is just extra overhead and latency for us... > > > > > > Any sugestions or comments appreciated... > > > > > > > > > Thanks, > > > James > > > > > > > > > > > > ___ > > > Devel mailing list > > > [EMAIL PROTECTED] > > > http://XFree86.Org/mailman/listinfo/devel > > > > > > > ___ > > Devel mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/devel > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Console Switching broke on NetBSD with XFree86 4.4.0
Matthias Scheler wrote: Hello, XFree86 4.4.0 works basically on my NetBSD-i386 1.6ZK system using an ATI Radeon 8500 LE. But when I try to switch back to text console the screen stays empty. It appears that restoring the text mode doesn't work properly anymore. Did anybody else experience this problem? Yes. Several OpenBSD users found that too. The attached diff fixes it. -- Matthieu Herrb Index: radeon_driver.c === RCS file: /cvs/XF4/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v retrieving revision 1.4 retrieving revision 1.5 diff -u -u -r1.4 -r1.5 --- radeon_driver.c 2004/02/13 22:41:18 1.4 +++ radeon_driver.c 2004/02/20 22:33:09 1.5 @@ -5497,7 +5497,7 @@ */ vgaHWSave(pScrn, &hwp->SavedReg, VGA_SR_MODE); /* Save mode only */ #else - vgaHWSave(pScrn, &hwp->SavedReg, VGA_SR_MODE | VGA_SR_FONTS); /* Save mode + vgaHWSave(pScrn, &hwp->SavedReg, VGA_SR_ALL); /* Save mode * & fonts & cmap */ #endif
Console Switching broke on NetBSD with XFree86 4.4.0
Hello, XFree86 4.4.0 works basically on my NetBSD-i386 1.6ZK system using an ATI Radeon 8500 LE. But when I try to switch back to text console the screen stays empty. It appears that restoring the text mode doesn't work properly anymore. Did anybody else experience this problem? Kind regards -- Matthias Scheler http://scheler.de/~matthias/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
howto get the XkbLayout with the C language
Hi, I've just tried to get the XkbLayout in my program, but It doesn't work for me at this moment. I caught the event, when the user changes the keyboard layout. But I cannot get the layout symbolic name as is in my XF86Config like "us" or "cz" or "de" or whatever I have there in the Option "XkbLayout" "us,cz" line. How can I programm it? I programm it in the C language. Any help appreciated Maca ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
xkb programming
Hi, I've just tried to get the XkbLayout in my program, but It doesn't work for me at this moment. I caught the event, when the user changes the keyboard layout (I set up the grp_shift_toggle in my XF86Config file). In my program I cannot get the layout symbolic name as is in my XF86Config like "us" or "cz" or "de" or whatever I have there in the Option "XkbLayout" "us,cz" line. How can I programm it? I programm it in the C language. Thank you in advance for help Maca -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
We are concentrating on developing games which utilise polished 2d graphics engines, rather than 3d. I know it sounds crazy but its what we want to do... With most 2d engines the number of pixels drawn is usually kept to a minimum, unless there is a huge amount of overdraw going on, then its nearly always faster to draw direct to the framebuffer. If we do need to scroll the whole screen, then we would try to alter start of viewport address rather than transferring the entire screen. I'm just concerned that the DGA extension will be removed with no adequete replacement. The main issue with DGA seems to be the way it requires root privs and can write to other parts of memory. Can we not have some sort of "/dev/dga" device or is this not the place to ask ;) is this not feasible? James On Sat, 6 Mar 2004 19:02:00 -0800 (PST) Mark Vojkovich <[EMAIL PROTECTED]> wrote: >I expect it will go away eventually. It's still the case for > most access patterns that rendering in system memory and then > copying the result to the framebuffer is faster than CPU rendering > directly to the framebuffer. Only the most simple game engines (write- > only SW scanline renderers) can benefit from direct framebuffer access. > Why aren't you using OpenGL? > > Mark. > > On Sun, 7 Mar 2004, James Wright wrote: > > > Hello, > > > >Apologies if this is the incorrect list to post to but i couldn't decide > > between the general "forum" > > list or this one. My question concerns the DGA extension in XFree86, whether it > > will be removed from > > future versions, and the alternatives. We are currently in the process of > > developing games for the > > Linux OS. We require direct access to the video framebuffer, the ability to change > > resolution, refresh > > rate, indexed palettes, and the ability to alter the start screen position pointer > > (for hardware > > scrolling). At first we wrote our 2D drawing libs to use SVGALib, but after > > numerous problems with memory > > leaks and bad support for many gfx cards we switched to X11->DGAv2. We are > > reasonably happy with DGA as > > it stands, with the only annoyance being that it requires root privs. I have seen > > it mentioned that > > DGA could be removed in future XFree86 releases, is this true? If so, what are the > > alternatives for us > > to use? It is obvious that there are alot of apps out there that really can't > > justify the use of DGA, > > but I feel that this application (games) really can benefit from using it. Any > > extra layers between > > our drawing and the framebuffer is just extra overhead and latency for us... > > > > Any sugestions or comments appreciated... > > > > > > Thanks, > > James > > > > > > > > ___ > > Devel mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/devel > > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
