[Xpert]Re: [Dri-devel] Re: [Dri-devel][PATCH] Segfault in DRI Xserver extension
mScreens) {
+ client->errorValue = stuff->screen;
+ return BadValue;
+}
if (!(pDrawable = (DrawablePtr)SecurityLookupDrawable(
(Drawable)stuff->drawable,
@@ -409,6 +448,11 @@
REQUEST(xXF86DRIGetDrawableInfoReq);
REQUEST_SIZE_MATCH(xXF86DRIGetDrawableInfoReq);
+if (stuff->screen >= screenInfo.numScreens) {
+ client->errorValue = stuff->screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client->sequence;
@@ -483,6 +527,11 @@
REQUEST(xXF86DRIGetDeviceInfoReq);
REQUEST_SIZE_MATCH(xXF86DRIGetDeviceInfoReq);
+if (stuff->screen >= screenInfo.numScreens) {
+ client->errorValue = stuff->screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client->sequence;
@@ -528,6 +577,11 @@
DrawablePtr pDrawable;
REQUEST_SIZE_MATCH(xXF86DRIOpenFullScreenReq);
+if (stuff->screen >= screenInfo.numScreens) {
+ client->errorValue = stuff->screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client->sequence;
@@ -554,6 +608,11 @@
DrawablePtr pDrawable;
REQUEST_SIZE_MATCH(xXF86DRICloseFullScreenReq);
+if (stuff->screen >= screenInfo.numScreens) {
+ client->errorValue = stuff->screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client->sequence;
Index: glx/glxcmds.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/GL/glx/glxcmds.c,v
retrieving revision 1.8
diff -u -r1.8 glxcmds.c
--- glx/glxcmds.c 25 Nov 2002 19:58:38 - 1.8
+++ glx/glxcmds.c 13 Dec 2002 15:52:01 -
@@ -761,7 +761,7 @@
int i, p;
screen = req->screen;
-if (screen > screenInfo.numScreens) {
+if (screen >= screenInfo.numScreens) {
/* The client library must send a valid screen number. */
client->errorValue = screen;
return BadValue;
@@ -1466,7 +1466,7 @@
ClientPtr client = cl->client;
xGLXQueryExtensionsStringReq *req = (xGLXQueryExtensionsStringReq *) pc;
xGLXQueryExtensionsStringReply reply;
-GLint screen;
+GLuint screen;
size_t n, length;
const char *ptr;
char *buf;
@@ -1475,7 +1475,7 @@
/*
** Check if screen exists.
*/
-if ((screen < 0) || (screen >= screenInfo.numScreens)) {
+if (screen >= screenInfo.numScreens) {
client->errorValue = screen;
return BadValue;
}
@@ -1511,7 +1511,7 @@
xGLXQueryServerStringReq *req = (xGLXQueryServerStringReq *) pc;
xGLXQueryServerStringReply reply;
int name;
-GLint screen;
+GLuint screen;
size_t n, length;
const char *ptr;
char *buf;
@@ -1521,7 +1521,7 @@
/*
** Check if screen exists.
*/
-if ((screen < 0) || (screen >= screenInfo.numScreens)) {
+if (screen >= screenInfo.numScreens) {
client->errorValue = screen;
return BadValue;
}
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Savage and nVidia DRI drivers
José Fonseca wrote: Actually my main interest is the learning experience of making a DRI driver from ground up - experience which I plan to share by writing a thorough HOWTO describing the steps and explaining the working of a driver from the high-level structure to the low-level implementation details. (You already can see the very first writings on http://dri.sf.net/doc/howto/) Great! -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]running 8-bit PC apps under 24- or 32-bpp X?
Dr Andrew C Aitchison wrote: On Wed, 30 Oct 2002, Josh Fryman wrote: ok. this aside. can someone explain to me why a 24- or 32-bpp X can't allow apps that demand 8-bit PC to run, and just provide them with an 'emulation' wrapper? i'd _really_ like to get rid of the vnc go-between for a wide variety of reasons. it seems like an obvious thing, but i can't figure out how to make it work. 8 bit on 24/32bit support hasn't been written yet. 8bit on X has an extra feature which made it difficult to produce a good solution on some hardware, but we now think we have a good solution for 24bit cards which currently support "DirectColor" visuals (most recent and current hardware). I've started looking at implementing this, but can;t promise when it will be ready; I'm a volounteer, and work and life take priority. Josh, In the mean time, you could look at the 8 over 24 overlay support that's available in some drivers like the g400...there might be others. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]fast display
Franco Bevilacqua wrote:
Hi folks,
I acquire images in gray levels from at 200 fps from a dsp board.
Each image has a fixed dimension of 640*532 of gray levels.
I need to display 30 fps without overloading the processor.
I need also to transform the image using the opengl filter.
I have used XShmtPutImage to display the images but, It uses 80% of the
main
process for displaying images. It's too much.
Does someone knows how can I do to decrease the processor usage for the
display.
I thought to display the images directly in the graphics card overlay,
but
I've not exeperiency to program video under linux.
Does someone can give some clues, may be, by using DRI driver or video
driver.
Thanks a lot for your help.
Franco
The latest open source ATI R200 3D driver contains support for fast
image transfers from AGP space. You might try posting to
[EMAIL PROTECTED] if you'd like more information on how to use that
mechansim.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Question about X protocol
Dmitry Yu. Bolkhovityanov wrote:
Hi!
As I understand, when an X server deals with clients having
different byte order, it is the server who does LSB<->MSB conversion, not
the client. Is there any documentation which lists the reasons of that
decision?
This architectural decision was made many years ago. I don't know if
any documentation exists. However, from an architectural perspective it
makes perfect sense. The XLib client side library tries to stay thin
where possible and defer all heavy lifting to the server side of the
implementation.
Why do you ask?
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]i830 refuses to run in 1400 x 1050
Martin van Es wrote: Hi, Let me first apologize for posting a newbie question that may have been covered before (I did search the archives and I did find some references to it, but thusfar was not able to solve my problem). I am a little ashamed (and spoilt) to admit that X is running like a charm, but that I'm just not satisfied yet since my LT has a 1400 x 1050 TFT screen and X 'only' uses 1280 x 1024 of it. The chipset in the LT is the cursed i830 (dual headed, see "No matching device for PCI:0:2:1 found"). From the XFree86.0.log it seems that it asks the BIOS for supported resolutions and for some reason it thinks it can only do 1280 x 1024 (at least on Pipe A, whichever that may be) and hence starts up using that. Can anybody tell me if there are patches for the i810 driver to 'override' BIOS reports and blindly go into a resolution given in the XF86Config file? No, the driver only supports modes that are supported by the BIOS. Maybe other improments for the i830 at this point? Hidden options? Where should I look to follow cutting-edge i810 drivers? XFree86 CVS. I boot with option vga=835 (1400 x 1050 x 24, so I read) but that seems to be of no use without proper kernel support. The VESA Frame Buffer driver should give you console support, but only if the BIOS supports that mode. The list of patches included for the i810 in the -72 distribution of X by RedHat: i810-dell-c400-broken-bios-1Mb-limit-workaround.patch i810-dont-force-XvMC-on-DRI-users.patch i810-dont-use-empty-for-loops-for-delays.patch i810-driver-update-cvs-20020617.patch i810-vtswitch-sync-fix.patch Maybe someone can say something sensible about the XFree86.0.log given below. Should I be concerned about the "Bad V_BIOS checksum" warning? Don't know. Is X falling back to VESA instead of using the i810, No, it appears to be correctly detecting i830 chipset and using i810 driver. or is it normal for X to query the VESA BIOS? For this driver, yes. Is it maybe because 1400 x 1050 is not a VESA standard and should I tell X not to use VESA? If so, how? I would recommend 2 steps, but I'm not certain how to execute them: 1 - Try to determine if the BIOS supports the mode you want. 2- If BIOS support is there, try getting the latest driver...it could be a driver bug. Do I need the experimental /dev filesystem support in my kernel for the /dev/dri/card0 to be detected? I wouldn't think so. This is a seperate problem and causes DRI to be disabled. Try building your i830 DRM kernel module with the same complier the rest of your kernel is built with. Also, I have very little luck compiling the i830.o drm module using the -72 sources (see failed i830.o line). The make script falls out on the i810_drv (how ironic). Any clues here? Try the latest sources from XFree86 CVS, or possibly the i830 binary packages from DRI at http://dri.sourceforge.net/downloads.phtml -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Backing store on Radeon?
Ian Romanick wrote: On Sun, Oct 20, 2002 at 05:09:08PM -0600, Jens Owen wrote: Making a direct rendering 3D driver render to a windows backing store area is a complicated task with very little benefit, IMO. Right, but shouldn't purely 2D targets work? I wouldn't think that the menus in twm are using OpenGL. :) At the very least, if it's not supported at all, when X is started with +bs, shouldn't it say just say no? That's the problem that I see. The user requests a feature, X says it's okay, but then it's not implemented. TWM isn't a good example, because it can efficiently handle expose events without the klunky backingstore feature enabled. Granted, there exists a small subset of applications that benefit from backing store, but it's a very small set in my experience. Most of the 2D applications that can't handle redraws can often achieve the same effect by rendering to pixmaps. Would disabling the DRI when backingstore is enabled give the semantic consistency you're looking for? I don't have a problem with that, because 99.99% of the users don't need backing store enabled. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: [Dri-devel] Backing store on Radeon?
Ian Romanick wrote: On Mon, Oct 21, 2002 at 10:06:13AM -0600, Jens Owen wrote: Would disabling the DRI when backingstore is enabled give the semantic consistency you're looking for? I don't have a problem with that, because 99.99% of the users don't need backing store enabled. I don't think that would help. I commented out the 'Load "dri"' and 'Load "glx"' lines from my XF86Config file and got the same behavior. Apologies. When I saw your question originally posted to the dri-devel list, I assumped it was related to direct rendering. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: [Dri-devel] r200 and libxaa
Mark Vojkovich wrote: On 21 Oct 2002, Michel Dänzer wrote: On Mon, 2002-10-21 at 02:05, Jens Owen wrote: José Fonseca wrote: On Wed, Oct 16, 2002 at 04:52:59PM +1000, Simon Bland wrote: I've seen ppl mention the libxaa.a from Fonseca seems to fix the problem with the screen blanking. Thing is I can't seem to find this libxaa.. Can anyone point me in the right direction for this? And can anyone confirm that this does seem to fix the screen blanking problem with the Radeon 8500. Initially I hosted on my website because there was no certain that it would help. But now that I know it does I've moved it to http://dri.sf.net/snapshots/extras/libxaa.a.bz2 and wrote a README.Sig11 on http://dri.sf.net/snapshots/ . Can anyone on Xpert comment on XAA binary incompatability? Does this just affect Forward compatability, i.e. older X environments with newer binary drivers? The problem appeared when I merged radeon driver fixes by Kevin E. Martin from XFree86 CVS to DRI CVS. They involved adding new fields to the XaaInfoRec struct; the fact that they were added in the middle of that struct caused the DRI binary snapshots, which were built against the new version of that struct but ran with an XAA module built against the old version, to crash and burn. I moved the new fields to the end of the struct, bumped the minor XAA version and added code to the radeon driver to only access the new fields if it's dealing with the new XAA. That worked as expected when I tested it here by copying libxaa.a from my Debian 4.2 installation into my DRI tree, which makes me suspect that the remaining problem with the snapshots is due to toolchain incompatibilities or something along those lines. I don't know why people do this. This change just broke NVIDIA's and ATI's binary drivers too. Any changes to structures that are referenced by drivers need to go at the end of the structures. Mark, I'd like to see driver level binary compatability continue, too. I'm not certain if Michael's changes have made it back to XFree86's CVS. I posted to this thread (and copied Xpert) because I read some posts to dri-devel that implied Michel's fixes weren't enough to restore driver compatability (old drivers, new XFree86 core and modules). If I'm mistaken, please let us know. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Synchronization with Vertical Retrace
Kral Stefan wrote: Hi! I want to do a fast, fluent animation with XFree86. To avoid tearing effects, I need to do two things: 1) Use some sort of double-buffering technique DONE (I use Xdbe or a pixmap+XCopyArea for that) 2) Synchronize the swapping of the buffers with TBD the vertical retrace of the screen. Only a few drivers actually wait for vertical retrace before swapping buffers that I know of, and they are all OpenGL drivers. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] r200 and libxaa
José Fonseca wrote:
On Wed, Oct 16, 2002 at 04:52:59PM +1000, Simon Bland wrote:
I've seen ppl mention the libxaa.a from Fonseca seems to fix the problem
with the screen blanking. Thing is I can't seem to find this libxaa..
Can anyone point me in the right direction for this? And can anyone
confirm that this does seem to fix the screen blanking problem with the
Radeon 8500.
Initially I hosted on my website because there was no certain that it
would help. But now that I know it does I've moved it to
http://dri.sf.net/snapshots/extras/libxaa.a.bz2 and wrote a README.Sig11
on http://dri.sf.net/snapshots/ .
Can anyone on Xpert comment on XAA binary incompatability? Does this
just affect Forward compatability, i.e. older X environments with newer
binary drivers?
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia libGL + Xfree libGL
Mark Vojkovich wrote: > On Sun, 13 Oct 2002, Jens Owen wrote: > > >>Mark Vojkovich wrote: >> >>>On Mon, 14 Oct 2002, Michael wrote: >>> >>> >>> >>>>I'm running my system with two graphic cards, and i'm not using xinerama. >>>>one of the cards is a nvidia and the other is a banshee, individually i can get >them both glx accelerated, i just need to copy the appropriate libGL depending on if >i want my banshee or nvidia accelerated, i'm wondering if it's possible in any way to >use multiple libGL's so i can get both my cards accelerated at the same time. >>>> >>> >>> >>> I don't think so. The separate libGL's could probably be solved with >>>some LD_PRELOAD magic, but there can only be one GLX extension in >>>the server (extensions aren't per-screen, they're server-wide). >> >>Mark, >> >>Have you, or anyone else at NVidia, considered reworking the device >>independent pieces of the GLX extension and OpenGL client side library >>from XFree86 to work with NVidia's binary drivers? >> > > >Not in a long time and never very seriously. I think our > implementations have diverged quite a bit (we didn't start with > the public SI and we hacked it quite a bit). Seems like alot > of work, especially since the XFree86 GLX doesn't support dlopening > libGLcore (correct?). Mark, The developers and integrators of the open source components (the DRI team) have given some thought to the integration of non-DRI based solutions as well. However, we're equally guilty of not mounting any serious effort to address this limitation. With NVidia and the DRI team working indepedently, neither effort has run into any technical limitations that couldn't be resolved; however, our lack of common infrastructure for device independent components does have a negative impact on both our efforts, as well as some negative impact on the Linux graphics industry in general. It is not a trivial effort to allow our diverse implementations to coexist at run time, and the DRI team is willing to contribute to any effort that enables the entire industry to use either implementation in a seamless manner. However, we need cooperation from closed source vendors to better understand their dependencies, interfaces and issues that need to be addressed for a common run time infrastructure. The existance of a dynamically loadable core is something we've considered, but it has not been a high priority for implementation. However, I think that priority could change, especially if it would be used as the basis for a common run time infrastructure that supports both our diverse implementations. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia libGL + Xfree libGL
Mark Vojkovich wrote: > On Mon, 14 Oct 2002, Michael wrote: > > >>I'm running my system with two graphic cards, and i'm not using xinerama. >>one of the cards is a nvidia and the other is a banshee, individually i can get them >both glx accelerated, i just need to copy the appropriate libGL depending on if i >want my banshee or nvidia accelerated, i'm wondering if it's possible in any way to >use multiple libGL's so i can get both my cards accelerated at the same time. >> > > >I don't think so. The separate libGL's could probably be solved with > some LD_PRELOAD magic, but there can only be one GLX extension in > the server (extensions aren't per-screen, they're server-wide). Mark, Have you, or anyone else at NVidia, considered reworking the device independent pieces of the GLX extension and OpenGL client side library from XFree86 to work with NVidia's binary drivers? Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Very Old E-Mail
The last few days, I've been receiving dozens of e-mails addressed to the XFree86 Xpert list that are 2-3 months old. Is anybody else seeing this problem with xpert mail? I'm not getting old messages for any of the other lists I follow... -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- Begin Message --- On Tue, Aug 13, 2002 at 03:02:55AM -0400, Brian A. Seklecki wrote: > > X11R6 seems to have support in: xc/programs/Xserver/hw/hp/ i can confirm -- i have compiled and used the server from R6.4 under hp-ux, and though the performance is not as good as the server shipped by hp, it does work. as far as what it wants in the way of kernel interface though, i'm not sure... -w ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert --- End Message ---
Re: [Xpert]Liberating the Dell Inspiron 2600
[EMAIL PROTECTED] wrote: >>Hi >> >>This is my first ever submission to a mailing list to get help. If I have got the >etiquette wrong, sorry - please advise. >> >>I am failing to get XFree86 to work on a Dell Inspiron 2600 at a screen resolution >of 1024*768. > > > Maybe this will help: > > http://www.pvv.org/~roarl/inspiron4100.txt > > It is the work of a frend and me. Kim, I believe Peter has a Intel 830 graphics chip, not the ATI Radeon mobility. Peter, Try the latest i810 driver from XFree86 CVS. It contains many fixes for memory allocation. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]gray bitmap on startup
Hans-Peter Jansen wrote:
> Hi *,
>
> since I'm using XFree86 (about 5 years now mostly successful, thanks),
> I ask myself this question:
> What is the gray bitmap on startup good for, and where did it come from?
>
> I would like to try to patch my XFree to get rid of it (if it is possible
> at all), so any hints, where to start on this is highly appreciated.
>
> current: 4.1.0/SuSE 7.3/mga and CVS from sunday, where I started digging
> after a successful build, but this package is _really_ huge. I started
> analysing xsetroot -gray, and searched for similar X-calls under
> xc/programs/Xserver, but failed to find suspicous calls?
>
> I would be really happy, if some kind mind would shed some light on this.
Hans-Peter,
I submitted a patch a few weeks back which disables the normal root
weave in favor of a black background. It hasn't been applied to the CVS
trunk, yet; but here's the original patch.
Regards,
Jens
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
--- xc/programs/Xserver/os/utils.c.jens Mon Jul 29 10:35:48 2002
+++ xc/programs/Xserver/os/utils.c Mon Jul 29 10:34:33 2002
@@ -496,6 +496,7 @@
ErrorF("-audit int set audit trail level\n");
ErrorF("-auth file select authorization file\n");
ErrorF("bc enable bug compatibility\n");
+ErrorF("-brcreate root window with black background\n");
ErrorF("+bsenable any backing store support\n");
ErrorF("-bsdisable any backing store support\n");
ErrorF("-c turns off key-click\n");
@@ -659,6 +660,8 @@
}
else if ( strcmp( argv[i], "bc") == 0)
permitOldBugs = TRUE;
+ else if ( strcmp( argv[i], "-br") == 0)
+ blackRoot = TRUE;
else if ( strcmp( argv[i], "+bs") == 0)
enableBackingStore = TRUE;
else if ( strcmp( argv[i], "-bs") == 0)
--- xc/programs/Xserver/include/opaque.h.jens Tue Jul 30 08:16:31 2002
+++ xc/programs/Xserver/include/opaque.hTue Jul 30 08:16:56 2002
@@ -75,6 +75,7 @@
extern Bool permitOldBugs;
extern Bool defeatAccessControl;
extern char* protNoListen;
+extern Bool blackRoot;
--- xc/programs/Xserver/dix/globals.c.jens Sun Jan 27 11:22:09 2002
+++ xc/programs/Xserver/dix/globals.c Mon Jul 29 10:29:28 2002
@@ -126,6 +126,7 @@
every compilation of dix code */
Bool loadableFonts = FALSE;
CursorPtr rootCursor;
+Bool blackRoot=FALSE;
ClientPtr requestingClient;/* XXX this should be obsolete now, remove? */
TimeStamp currentTime;
--- xc/programs/Xserver/dix/window.c.jens Mon Jul 29 10:36:10 2002
+++ xc/programs/Xserver/dix/window.cTue Jul 30 14:46:50 2002
@@ -101,6 +101,7 @@
#endif
extern Bool permitOldBugs;
+extern Bool blackRoot;
#if defined(NEED_SCREEN_REGIONS)
#define REGION_PTR(pScreen,pWin) \
@@ -345,6 +346,9 @@
for (j = len; j > 0; j--)
*to++ = *from;
+ if (blackRoot)
+ bzero(back, sizeof(back));
+
(*pGC->ops->PutImage)((DrawablePtr)pWin->background.pixmap, pGC, 1,
0, 0, len, 4, 0, XYBitmap, (char *)back);
Re: [Xpert]i830/i845G updates
he VideoRam option in your XF86Config file. Try using this in your "Device" section: VideoRam 16384 Also, there are additional 3D fixes for the i845G in the DRI trunk. Unfortunately, there's more work to do to get the nightly snapshot to include the i845G: http://dri.sourceforge.net/snapshots/i810-20020912-linux.i386.tar.bz2 But you can check the trunk sources out of CVS and make World. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]i830m xfree86
David Hawkes wrote:
> Hi:
>
> I would like to get the video going for Solaris 8 on a i830m box. Is
> the agp gart and drm required or can the modules provided with xfree86
> be used (with xfree of course) when bios provides a memory
> assignment.(no 3d required)
David,
AGP support is required to get additional memory for graphics operation.
However, if you can get by with the amount of memory reserved by the
BIOS, you should be able to run 2D with that.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: 845 driver (again)
Biswapesh Chattopadhyay wrote:
> OK - I updated hwdata from RawHide (which contains
> /usr/X11/lib/X11/Cards) and ran Xconfigurator again. This time the card
> and chipset got identified correctly, but still no luck :-( I'm
> attaching the log - any ideas ?
Looks like you're running out of memory for the graphics device. Log
shows only 1M allocated. Try bumping that up to something like 8 or 16M
in your XF86Config-4 file.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Intel 845 problems with XF 4.2.0
Biswapesh Chattopadhyay wrote:
> does the CVS version contain the Intel drivers ?
Yes.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH] Resuming to and suspending to disc with runningDRI clients
Charl P. Botha wrote: > Dear list, > > Attached please find a patch to the DRI CVS that enables suspending to and > resuming from disc with running DRI clients (3D Windows, ao). This is > different from the reinit solution that Michel Dänzer and I have proposed > and which Michel has refined: it allows suspending/resuming with active 3D > windows. I have tested this with the venerable glxgears at 1000 FPS (24bpp > display depth, no page flipping). > > This patch simply (ha ha) tries to re-initialise the only the Radeon > hardware after a resume. At the moment, I invoke the new code from > RADEONEnterVT() as it's idempotent during normal operation (I think). > > I would appreciate your review. I'm going to do more testing and > refinement as soon as I have more time. This week is filled with > RealLife(tm). Charl, I like the direction of this patch much better than the reinit stuff. Here's the positives as I see them: 1) Your looking at this as a hardware state issue, and I think that's a good tact. Hooking and extending the the Enter/Leave VT functionality is great way to go about this. 2) You've got a prototype working that shows, simply focusing on enhancing the amount of HW state that is saved and restored is all that's needed to address this issue. The final step that I would encourage before we make this a standard part of all 3D driver in XFree86 is to examine the redundancy in initial state setup and your new restore routines. I believe there is much code factoring that can be done. A little support at the device independent level and we can have one routine that sets state, whether we are initializing or restoring. This makes developing a driver easier and tracking down state issues much easier. So, if we can basically beef up the driver's Enter/LeaveVT support (or underlying state setup) we can handle the case of suspend and resume with the duplication. This also works well in that the server would effectively hold the lock across suspend/resume just like it does for VT switches...thus making sure the 3D driver doesn't access the hardware until the X server has completely restored the hardware state and released the lock. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Radeon, problem with dual head
[EMAIL PROTECTED] wrote:
> Have tried to configure a Radeon LY in Gericom M6T Laptop.
>
> In single head mode the display looks well in 1400x1050 and one can also
> zap through all resolutions without problem.
>
> ASAP one configures it for dual head the same modeline produces a stripe of
> unused display at the right and at the bottom.
> Also if one switches resolution at the secondary the LCD content is completely
> overwritten with garbage.
>
> Is it possible to use 3d-acceleration in combination with classic/cinerama on
> both heads at once?
It's possible, but support is not implmented in the Radeon driver.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]getting root window ptr from server side
Rich Richardson wrote:
> What is the best way to go about getting a pointer to
> the Root Window of a given screen, from within the
> Xserver -- I know it's pretty doable from the client
> side (via Xlib), but I haven't come across and
> "idioms" for doing so on the Xserver side...
WindowTable[pScreen->myNum]
WindowTable is a global data structure in the X Server.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Crash on Intel i815
Mark Cuss had in his server log:
> (WW) I810(0): xf86AllocateGARTMemory: allocation of 1024 pages failed
> (Cannot allocate memory)
> (II) I810(0): No physical memory available for 4194304 bytes of DCACHE
This could be the short term problem...AGP GART support is needed in
order to allocate more than the 1MB of memory. At 800x600x24bpp you
need more than 1MB.
The curious thing is why the driver didn't recognize this failure and
refuse the mode you requested.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]HP 700 series frambuffer support (GIO Graphics?)
Brian A. Seklecki wrote: > ...obviously this is quite a-ways down the road for port-700 series > development, but I was curious -- what are the chances of working torwards > XFree86 support for this series onboard FB? From my DMESG: > > "GIO Graphics" at mainbus0 (type a, sv 85) hpa f800 not configured > > The user's manual is available at: > > http://www.hp.com/workstations/support/archive/manuals/A2615-90602.pdf > > But it's very superficial. I'm having trouble finding info about this IC in > google. I'll try to get a serial number of the mainboard. Apparently the > HP-UX X server is based off of X11R5, so support has exists at one point or > another. X11R6 seems to have support in: xc/programs/Xserver/hw/hp/ > > Ideas? Brian, The HP 712 Workstation is over 10 years old. So realize that platform is similar in performance to a P5-150 with a Matrox Millenium graphics chip. I've got one here in my office if anyone wants to pay for shipping. I don't believe HP has released any specifications, but the Puffin Group was sponsered by HP to port Linux to HP-PA processors and may have gotten the graphics chip specs. The name of the graphics chip is "Artist". You can look at the sources in the xc/programs/Xserver/hw/hp tree. The ngle subdirectory has support for Artist under HP-UX 9.x, but it's purely unaccellerated. I'm not certain of the status for HP-UX 10.x or 11.x, but if you can get 9.x you can build Xhp in source form and see it work. There is a binary only module that comes in the NGLE directory. That provides hardware accelleration for screen clear and screen to screen copies. One of the biggest challenges you'll face trying to get this generation of HP graphics working on non-HPUX platforms is getting specs and interfacing with the graphics ROM interface. The interface is called STI for Standard Text Interface and reside below the normal system IODC ROM interface. The NGLE driver makes kernel calls ioctl(GC*...) to an HP-UX kernel driver that call the STI ROM directly. In summary, this would be a large mountain to climp (access to specs and reworking HP's architecture to work with XFree86). With HP's blessing and a lot of work, it's possible. However, it's only reward may be the journey itself. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xfree 4.2/Radeon 7500/Xinerama
Mark Lane wrote:
> Can some one tell me what I have done wrong with my Xinerama setup?
>
> http://www.harddata.com/xfree/XF86Config-4
> http://www.harddata.com/xfree/XFree86.0.log
>
> I downloaded the current drivers from dri today.
>
> Thanks,
Mark,
I have not idea why you are getting the unresolved symbols. Have you
tried uninstalling the DRI driver to see if the problem goes away?
Based on your log file, it looks like you're trying to run in a dual
head mode (one card/rendering pipeline with multiple displays). You can
see a block diagram of the needed components at
http://www.tungstengraphics.com/dri/Tradition_Xinerama_DH.txt
Unfortunately, this driver does not support direct rendering in any dual
head modes, but I understand that many people have been able to get the
2D X Server rendering to work with dual head.
Regards,
Jens
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Is the XFree development stuck in a dead end?
Mike A. Harris wrote: > On Tue, 16 Jul 2002, José Fonseca wrote: >> >>I'm a mechanical engineer - my formation includes just an intro to >>Pascal and Fortran programming. My programming skills were self tought >>since my 10 years, but have very few things that I can show as programming >>experience proof. Not to mention window systems: up to this date I've >>still to make one GUI or 3D application. >> >>Nevertheless, after switching to Linux only on last October, I've study the >>OpenGL spec, made a developer's FAQ with all information I could gather >>the DRI, got CVS access, and together with another guy (whom background >>isn't also computer science but art) brought the Mach64 DRI driver from >>barely a draft to the point which is almost ready to inclusion in a >>release. This included getting familiar with CVS, linux kernel programming, >>the DRI architecture, X, and a almost complete rewrite of the code due >>the Mesa 4.0 architectural changes. >> > > You're one of the few. Somewhat of an "exception" that is to the > general rule. Here is some advice from a non-core team member w/o CVS access...take it for what it's worth. Jose is "exceptional" and there are more developers in the world with his talent and ambition that haven't discovered XFree86, yet. If you can find a way to embrace those developers, you will find fresh new blood, with fresh ideas and a the ambition and capabilities on driving that forward. We have all seen the newbie who comes in and makes a bunch of noise to no avail. However, creating barriers to reduce this impact is also a deterrent to attracting the productive young developer. The challenge facing your project is to find a way to inform, enable and support new developers to your project. I sincerely hope that a few of the core team members are listening, and perhaps reading between the lines. I also commend Jose for addressing this subject in an open and honest dialog. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]glXMakeCurrent & dummyContext problem
Meelis Roos wrote:
> $ glxinfo
> name of display: localhost:10.0
> Xlib: connection to ":0.0" refused by server
> Xlib: Client is not authorized to connect to Server
> display: localhost:10 screen: 0
> direct rendering: No
>
> If the display is different from :0.0 (:1.0, remote display, whatever)
> then GLX initialization tries to connecxt to :0.0 and fails. Sometimes
> this takes time, depending on user configuration. For example, on my
> home computer I have to wait quite a long for this :0.0 connect timeout
> for some reason when running GLX things on :1.0. I have seen this
> behaviour several times and today I decided to find out what's wrong.
>
> If this si the wrong list and there is a better list for GLX library
> problems, please direct me there.
>
> Below is an excerpt from ltrace -S glxinfo to find out the call trace.
> It basically shows that glxinfo calls glXMakeCurrent with correct
> display struct but inside glXMakeCurrent a connection to :0.0 is made.
>
> A little digging in the code shows that glXMakeCurrent saves old
> context:
> oldGC = __glXGetCurrentContext();
>
> __glXGetCurrentContext() finds no previous context and uses dummyContext
> instead. Somehow dummyContext is used without check later and it seems
> that this results in spurious connect to default display :0.0. I have
> not determined where the exact call is since I don't have time to
> recompile it with debug info currently.
>
> This trace is from XFree 4.1.0-17 Debian package (because that's what
> I'm running on the computer where ltrace works) but I tried it with
> 4.2.99.1 CVS on another computer (sparc, so no ltrace) and the result
> was similar - it still connected to :0.0. Even more, it segfaulted
> somewhere after that but my current binaries are without debug info and
> I can't find out what exactly happened. Anyway, this GLX problem is
> present both in 4.1 and 4.2 current.
>
> 17369 XCreateWindow(0x08053b00, 49, 0, 0, 100)= 0x0302
> 17369 glXCreateContext(0x08053b00, 0x08055848, 0, 1, 1
> 17369 malloc(1308
> 17369 SYS_brk(0x08057000) = 0x08057000
> 17369 <... malloc resumed> ) = 0x08055d10
> 17369 malloc(262140
> 17369 SYS_mmap(0xbb04, 262144, 0x40337dd0, 266240, 0x8000) = 0x40392000
> 17369 <... malloc resumed> ) = 0x40392008
> 17369 <... glXCreateContext resumed> )= 0x08055d10
> 17369 glXMakeCurrent(0x08053b00, 0x0302, 0x08055d10, 1, 1
> 17369 SYS_write(3, "\217\024 ", 232) = 232
> 17369 SYS_read(3, ???, 32)= -11
> 17369 SYS__newselect(4, 0xbaac, 0, 0, 0) = 1
> 17369 SYS_read(3, "\001", 32) = 32
> 17369 XOpenDisplay(":0.0"
> 17369 SYS_uname(0xb534) = 0
> 17369 SYS_socketcall(1, 0xb774, 0x401e8fdc, 0x401e69e8, 60) = 4
> 17369 SYS_uname(0xb574) = 0
> 17369 SYS_uname(0xb474) = 0
> 17369 SYS_socketcall(3, 0xb754, 0x401feac0, 19, 0xb7cc) = 0
> 17369 SYS_uname(0xb5b4) = 0
> 17369 SYS_fcntl64(4, 2, 1, 2, 4) = 0
> 17369 SYS_access(0x08054678, 4, 0x401e8fdc, 0x08054678, 0xb82e) = 0
> 17369 SYS_open("/home/mroos/.Xauthority", 0, 0666) = 5
> 17369 SYS_fstat64(5, 0xb58c, 0x40338a40, 0x4033c36c, 5) = 0
> 17369 SYS_mmap(0xb554, 0xb58c, 0x40337dd0, 0x080568d8, 4096) = 0x40016000
> 17369 SYS_read(5, "", 4096) = 304
> 17369 SYS_read(5, "", 4096) = 0
> 17369 SYS_close(5)= 0
> 17369 SYS_munmap(0x40016000, 4096)= 0
> 17369 SYS_brk(0x08058000) = 0x08058000
> 17369 SYS_writev(4, 0xb954, 1, 1, 4) = 12
> 17369 SYS_fcntl64(4, 3, 0, 3, 4) = 2
> 17369 SYS_fcntl64(4, 4, 2050, 4, 4) = 0
> 17369 SYS_read(4, ???, 8) = -11
> 17369 SYS__newselect(5, 0xb8cc, 0, 0, 0) = 1
> 17369 SYS_read(4, "", 8) = 8
> 17369 SYS_read(4, "Client is not authorized to conn"..., 48) = 48
> 17369 SYS_write(2, "Xlib: connection to ":0.0" refus"..., 52) = 52
> 17369 SYS_write(2, "Client is not authorized to conn"..., 45) = 45
> 17369 SYS_write(2, "\r\n", 2) = 2
> 17369 SYS_socketcall(13, 0xb8c4, 0x401e8fdc, 0x08056868, 0x08056820) = 0
> 17369 SYS_close(4) = 0
> 17369 <... XOpenDisplay resumed> )= NULL
> 17369 ma
Re: [Xpert]Best way to handle Resize and move ?
tchiwam wrote:
> I don't know if this belong here at all so please reply so reply to me
> directly.
>
> I am Writing some simple GLX viewer and I am wondering what is the best
> way to handle resize and move since one render takes few seconds. I know
> that expose has a count that you can use to redraw, but for the Configure
> Notify what is the best way to Fix it so it doesn't redraw all the frames
> on each resize or move step ?
Philippe,
I'll add to Mark's comments by saying some hw/driver configurations can
help minimize expose events. If your hardware supports RGB overlays,
and the driver supports two seperate cliplists for image and overlay
planes, then expose events can be minimized. Your GUI (including all
pop up and transient windows) would run in the overlays (they would need
to be your default visual), and then your application should create it's
main viewing window in the image planes. In this configuration,
transient overlay windows do not destroy color data in the image planes.
Consequently, the server would not need to generate expose events for
this case.
Regards,
Jens
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A few questions regarding the XFree86-DGA extension
Owen Taylor wrote: > Juliusz Chroboczek <[EMAIL PROTECTED]> writes: > > >>MV> DGA really shouldn't be used and I regret that it's still in the >>MV> X-server. I would like it to disappear in XFree86 5.0. >> >>Mark, >> >>I fully agree with your feeling, and I am sincerely sorry to say what >>I'm about to say. >> >>There is no denying, though, that there are applications that want to >>do client-side rendering -- and I think that's a perfectly legitimate >>thing to do. The obvious solutions (PutImage and ShmPutImage) either >>involve one copy too many, or else require you to put your rendering >>buffers in a shared memory segment. >> >>I may be mistaken, but as far as I can see, the only way to do a >>direct blit from a random client-specified buffer is DGA. Unless we >>provide a different way to do that, there is little chance of DGA >>going away with no loss. >> > > If you are willing to give up the "Random" then, you can use ShmPixmaps > or ShmImages and have: > > Blit from framebuffer specified data to screen - XShmPutImage > Blit from RGB data to screen - RENDER > Blit from YUV, etc to screen - Xv > > (I know less about the last.) I'll add that image transfers can also be done via OpenGL using direct rendering. That would be a more secure and reliable as well. > In the cases that this doesn't work, well, the overhead of an extra > memory => memory copy is just not all that significant these days. > I don't think it is worth throwing away the security and robustness > model and using DGA. I'd like to see DGA go away, too. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Documentation on XF86 extensions to X protocol?
[EMAIL PROTECTED] wrote: > > The general answer is, the usual, "it depends". The documentation for different > extensions is in different places, if it exists at all. Should we consider putting protocol documents in a common place under the source tree? Currently, the DRI extension encoding can only be found at http://dri.sourceforge.net/doc/dri_extensions_low_level.txt -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Re: XIE and PEX5?
Dr Andrew C Aitchison wrote:
> SGI then made a good job of marketing the OpenGL API (though screw-ups
> allowed a rival to release the first implementation), and the
> Farenheight (sp?) deal with Microsoft must have damaged alternatives
> such as PHIGS.
More fun with history :-)
By the time Farenheight was announced, the OpenGL vs PEX war was over by
a couple of years at least. However, Farenheight could be consider the
beginning of the end WRT Microsoft actively endorsing OpenGL.
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Re: XIE and PEX5?
Juliusz Chroboczek wrote: > > MH> Even moreso I hope nobody uses PEX. ;o) > > Could somebody smart explain why PHIGS was abandoned? Is that because > OpenGL is strictly more expressive? > > (Not being argumentative here, but genuinely incompetent and curious.) I'll add to the historical comments by mentioning that OpenGL was being supported by Microsoft (at the time, anyway). PEX was tightly integrated with X, making it impractical in the low cost PC environment of the time. >From my perspective, working in the PEX camp at the time, that was the key issue that decided the OpenGL vs PEX war. I'm sure you'll get many other perspectives from the OpenGL camp. Isn't there a saying how the victor get's to write the history books? That said, I'm glad to support OpenGL. It has much better integration with X than Direct3D :-) -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]DRI and glXCopyContext, or one context for 2 windows
Joe Krahn wrote: > > I am trying to use one context state for two windows. > Is glXCopyContext supposed to work for DRI? > > Alternatively, I can actually use one context and point > it to the window I want to render in. Apparently, this > is an unusual thing to do. It works on SGI (as uaual) > but was able to crash XFree86 DRI, Nvidia, and Xig servers. > Nvidia and Xig fixed the problem, but DRI is still broken. > DRI doesn't crash from this any more, but it gives serious > artifacts. > > Without glXCopyContext, a workaround is really hard, > other than not using DRI. > > Any ideas? This is probably another case of trying the DRI CVS. Joe, Post a pointer to your test app on [EMAIL PROTECTED] -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama public review announcement
Mark Vojkovich wrote: > > On Thu, 6 Jun 2002, Jens Owen wrote: > > > Mark Vojkovich wrote: > > > > > > On 6 Jun 2002, Juliusz Chroboczek wrote: > > > > > > > Congratulations. > > > > > > > > To what extent is the version of Xinerama that X.Org are proposing > > > > compatible with the XFree86 one? > > > > > >It's a different API and the protocol is not compatible. XFree86 > > > will be able to offer both protocols to maintain compatibility with > > > the few window managers that currently use our version, but we should > > > deprecate the old API and eventually remove it. > > > > Mark, > > > > How much would the XFree86 internal implementation need to change to > > support the proposed API? Can we minimize the impact to driver > > maintenance and other development intensive areas within XFree86? > > > >There is no change to the implementation or drivers, just the > protocol. The SI is going to be using XFree86's implementation, > which is mainly why I've been on the X.org Xinerama task force. That's great news. Thanks for your hard work. > Part of the Xinerama task force's goal was to have a fixed implementation > and I'm glad XFree86's implementation was used as the starting > point for that. I've been integrating the additional fixes into > CVS as they've been developing. VSW5 is also being modified to > be Xinerama aware so there should be no failures when everything > is completed. We already pass everything except for one issue > that is still being investigated. > >There are really only two significant changes: the protocol > reflects the ability to have multiple Xinerama screens, though > no implementations will likely support this for some time. And > second, the addition of a XINERAMA_CENTER_HINT which is a root window > property to tell clients where they should consider the center > of the screen. Outside of the Xext protocol interface we need > to initialize the root window property, and that's about it. > I'll integrate all that stuff when it's finalized. Good info. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama public review announcement
Mark Vojkovich wrote: > > On 6 Jun 2002, Juliusz Chroboczek wrote: > > > Congratulations. > > > > To what extent is the version of Xinerama that X.Org are proposing > > compatible with the XFree86 one? > >It's a different API and the protocol is not compatible. XFree86 > will be able to offer both protocols to maintain compatibility with > the few window managers that currently use our version, but we should > deprecate the old API and eventually remove it. Mark, How much would the XFree86 internal implementation need to change to support the proposed API? Can we minimize the impact to driver maintenance and other development intensive areas within XFree86? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XF86+nvidia+OSMesa trouble
Yannick Perret wrote: > > Hi. > > I have a linux debian (the last woody) with a geForce2 AGP (64Mo). > I have the XF86-4 and I have installed the last nvidia drivers in order > to obtain the better 3D acceleration. > > For my work, I have to make off-screen rendreding and I used > to use osMesaCreateContext which generates a 'fake' context for GL, > allowing rendering in user memory. > > I can't manage to make the lib OSMesa working with the nvidia drivers > (missing some symbols in libGL.so)... > I tried to bypass this problem using glx. I tried to make GL using > a X11 pixmap for rendering (which is supposed to be possible as shown > in the 'glxpixmap' demo), but X complains about a bad XPixmap id when > switching to the pixmap context... > > I suppose their is a way to make off-screen rendering using hardware > acceleration... > > Any clues ? > > By the way, I don't manage to use pure Mesa libs... I installed Mesa > and I link a small test program with it. It generates a 'core dump' at > execution (before executing any code... so it is a lib problem...). Yannick, I believe NVidia replaces the standard XFree86 libGL.so with their own. Standalone Mesa does this as well. It sure would be nice to have all this supported in a single library. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]trying to build a ~16ft^2 x video wall
Jacob Kuenzel wrote: > The wall will consist of five PCs and sixteen identical monitors and > video cards. It should work as follows: four of the PCs will have four > video cards each and will run an X server on each video card, possibly > using Xinerama to combine them. The fifth PC will be networked with the > four other PCs, will use some mechanism to combine the sixteen remote > displays (four if Xinerama is used) into one large display, and will act > as a head-end for this display. Take a look at the dmx-0-1-branch at http://dri.sourceforge.net I don't know how far along the development is, but I believe this work is designed to address just those needs. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: linux-drm-4.2.0-kernelsource.tar.gz fixes for 2.5.X
José Fonseca wrote: > I would be nice to know what is the current state of affairs? I'll be happy to review the nitty gritty details...I'll post this to the dri-devel list. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: linux-drm-4.2.0-kernelsource.tar.gz fixes for 2.5.X
Jose, I recommend a full two way merge (DRI->kernel and kernel->DRI). The kernel->DRI changes can be submitted directly to our repository for testing. The DRI->kernel changes require a patch be submitted to the kernel team. If we need two patches (for 2.4 and 2.5) that's okay--but we should try to end up with a common driver source for both kernel versions in our repository, if at all possible. Posting these patches on the DRI site is for the purpose of getting some alpha testing exposure and code review before submitting to the kernel team. Once we have merged sources in both repositories, then David and Alan can pick up the latest from our repository. Getting these fixes out minimizes our need to create patches relative to all the verious places the kernel DRM drivers can be found. Does this plan cover our needs, or am I overlooking something? "José Fonseca" wrote: > > Micah, this is a subject that although concerns Xpert list too it's more > appropriate to the dri-devel list. > > Jens, I guess that we need to start hosting kernel patches for the > different linux versions. We also need to differentiate the patches that > should be applied against the linux kernel and those that should be > applied against the XFree tree and/or Alan's kernelsource package. > > José Fonseca > > On 2002.05.13 04:21 Micah Galizia wrote: > > I have no idea where I should be submitting patches to code for, but I > > managed to get DRM working under 2.5.15 with my radeon. I've attached > > the patch to this message (I saw someone else do it first), if I'm > > putting this in the wrong place, please correct me! > > > > Not much to it really! Just renamed some things. > > On 2002.05.10 20:24 Micah Galizia wrote: > > Hi. I've been playing with the source code, trying to get accelleration > > for my radeon. I got it to compile with "make -f Makefile.linux > > radeon.o" and there are no warnings or errors. I'm going to keep > > working on the rest of it, so how would you like it sent back to you? > > I'm new to this kernel hacking -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Window ID
Bharathi S wrote: > > On Mon, 22 Apr 2002, Vladimir Dergachev wrote: > > > > How find the window id by using the following structures > > > Display, Drawable, Graphics Context ? > > > > AFAIK, Window id is the same thing as the drawable, provided the drawable > > points to the window. I.e. where the man page says Xblahblah function > > takes a drawable as an argument it means that you can either pass a window > > id or a pixmap (but not XImage) handle to it. > > Thank you Vladimir Dergachev > > Most of the functions taking Pixmap(DRAWABLE) as argument. > I need the window id for maintaining a virtual buffer > and window id as the key. > > How the Xserver finding the window id ? > Bcoz we are sending only dpy, pixmap, GC ! Bharathi, A pixmap is a drawable, a window is a drawable, but a pixmap is *not* a window. You can, however get the root window from a display structure. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Can Some one Help me Out On porting of X-Server dirvers into Windows
Balarama Chandra N R wrote:
> DISCLAIMER: Information contained and transmitted by this E-MAIL is
> proprietary to MASCOT SYSTEMS LTD
This disclaimer isn't going to help you get much response on an open
source mailing list.
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]AGP failed to initialize
Neil Leathers wrote: > >From lspci > 00:00.0 Host bridge: Acer Laboratories Inc. [ALi]: Unknown device 1647 (rev 04) > 00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5247 > 00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03) > 00:04.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c4) > 00:06.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03) > 00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV] > 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) > 00:11.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 SM unload the R128 and AGP modules and reload just the AGP module. What do you get in the last few lines of dmesg? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]using two X servers for a single session
Ricardo Baratto wrote: > > if you only care about opengl apps you could use wiregl > http://graphics.stanford.edu/papers/wiregl/ or the followon project called "Chromium" found at http://chromium.sourceforge.net -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Extension GLX missing
Dave Williss wrote: > > Ok, here's another related question. > I've got an OpenGL application, but it's insisting on using client-side Mesa > even though my X server supports the GLX extension. How do I tell it to > stop that? Dave, The libGL.so provided by standalone Mesa is probably forcing this. If you want to use the GLX extension you need to go back to the one provided by XFree86. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Extension GLX missing
Dave Horsfall wrote: > > On Tue, 12 Mar 2002, Derrik Pates wrote: > > > You're displaying X apps to an Xplora Xterminal. It only knows the X > > extensions that are built into Xncdxpl (not a whole lot). The extensions > > involve X-server-side code - since the X server doesn't support them, > > you can't use them. Sorry. > > So how come Xfree86 4.0.1 works with GLX on the same Xterm? It looks like you were actually using the Mesa client side software renderer the first time around. No GLX support needed. It just renders with standard X11 primitives. When you installed a newer version of XFree86, you probably over wrote the Mesa libGL.so, with the XFree86 version which, by default, doesn't support a client side software renderer. Try updating and installing Mesa, again. You can find source at http://www.mesa3d.org -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]OpenGL overlay with Matrox G400
Barry, You can look at it as a limitation of the Matrox driver, if you prefer. I believe Mark is trying to point out that none of the OGL renderers in XFree86 currently work with overlays. Regards, Jens Barry Branham wrote: > > The Mesa-demos RPM contains 'glxinfo.c' which has the line: >glXGetConfig(dpy, vInfo, GLX_LEVEL, &attribs->level); > > which is how it determines the 'level' parameter in the listing below. > SGI open sourced GLX in Feb '99 for XFree86 so why wouldn't it know > about overlays? > It seems to me this is a Matrox driver problem or something in my > configuration. > > Barry > > Mark Vojkovich wrote: > > > I didn't think the GLX code in XFree86 (Mesa based, or DRI) knew > >anything about overlays. > > > > Mark. > > > > > >On Wed, 27 Feb 2002, Barry Branham wrote: > > > >>I'm having trouble getting an overlay visual with the following code: > >> > >>int n = 0, list[5]; > >>list[n++] = GLX_LEVEL;// overlay planes > >>list[n++] = 0;// overlay planes > >>list[n++] = GLX_BUFFER_SIZE;// get at least 2 bits > >>list[n++] = 2; > >>list[n++] = None; > >> > >>vis = glXChooseVisual(XtDisplay(_mgrWidget), > >>XScreenNumberOfScreen(XtScreen(_mgrWidget)), list); > >> > >>the return is NULL. > >> > >>I'm using RedHat 7.2 with all the latest updates including XFree86 4.1.0-15 > >>I've used the 'Option "overlay"' line in XF86Config-4. > >>My root visual is TrueColor by starting the Xserver with '-cc 4' > >>I'm using the latest Matrox drivers. mga_hal is loaded but 'DRI' is not > >>enabled. > >> > >>glxinfo -t gives: > >> > >>[cts6 bhb]$ glxinfo -t > >>display: :0.0 screen:0 > >>direct rendering: No > >>server glx vendor string: SGI > >>server glx version string: 1.2 > >>server glx extensions: > >>GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context > >>client glx vendor string: SGI > >>client glx version string: 1.2 > >>client glx extensions: > >>GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context > >>GLX extensions: > >>GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context > >>OpenGL vendor string: VA Linux Systems, Inc. > >>OpenGL renderer string: Mesa GLX Indirect > >>OpenGL version string: 1.2 Mesa 3.4.2 > >>OpenGL extensions: > >>GL_ARB_multitexture, GL_EXT_abgr, GL_EXT_blend_color, > >>GL_EXT_blend_minmax, GL_EXT_blend_subtract > >>glu version: 1.1 Mesa 3.4.2 > >>glu extensions: > >>GL_EXT_abgr > >> > >>Vis Vis Visual Trans buff lev render DB ste r g b a aux dep > >>ste accum buffers MS MS > >> ID Depth Type parent size el type reo sz sz sz sz buf th > >>ncl r g b a num bufs > >>> > >>0x25 8 PseudoColor 0 24 0 ci 1 0 0 0 0 0 0 16 > >>0 0 0 0 0 0 0 > >>0x26 8 GrayScale0 24 0 ci 1 0 0 0 0 0 0 16 > >>0 0 0 0 0 0 0 > >>0x27 24 TrueColor0 24 0 rgba 1 0 8 8 8 0 0 16 > >>0 0 0 0 0 0 0 > >>0x28 24 TrueColor0 24 0 rgba 1 0 8 8 8 0 0 16 > >>8 16 16 16 0 0 0 > >> > >> > >>So there is a PseudoColor visual available. But it's level is 0. I > >>need a GLX_LEVEL 1 visual. > >> > >>Any suggestions will be much appreciated. > >>Thanks > >>Barry > >> > >> > > > >___ > >Xpert mailing list > >[EMAIL PROTECTED] > >http://XFree86.Org/mailman/listinfo/xpert > > > > -- > Barry Branham, Computer Operations Engineer > Cardiothoracic Surgery Research > Washington University School of Medicine > [EMAIL PROTECTED] (314)362-8305 > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Vladimir Dergachev wrote: > Also, I can make drm driver work nice with older 2d drivers - as soon as > someone will show me a way to tell the version of the 2d driver that is > accessing the drm driver. How about using a new set of IOCTL numbers for the new interface--then you'll know whether you have an old or new driver accessing it. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andp ossibly radeonDMA functions
Ian Romanick wrote: > each part (DRM and 2D X driver) have to > magically detect what the other part is capable of doing, and magically do > the right thing. > > Here are the possible version combinations: > > 1. New DRM + new 2D X driver > 2. Old DRM + new 2D X driver > 3. New DRM + old 2D X driver > 4. Old DRM + old 2D X driver If the client side 3D drivers are affected, you would also need to factor old and new 3D drivers in to make 8 cases--but I certainly hope the new DRM driver will support both old and new user space drivers simultaneously [cases 1&3]. If so, adding the 3D driver would just be redundant. > Case 4 is trivial, and I won't consider it any further. > > In the remaining cases, each the DRM and the 2D X driver need some way to > determine the capabilities of the other part so that they can know how to do > the mapping. I believe that there is already some mechanism for determining > the DRM version (drmGetVersion?). This makes cases 1 and 2 trivial. The > new 2D X driver will determine the DRM version, and either setup the new > mapping and support video capture, or log a message (or something similar) > so that the user knows that video capture is unavailable. Good idea. The DRM minor should be bumped anyway, and the new 2D driver could check to see if the minor number was >= the version it needed for video support. > Here we have the > potential for reduced functionality, but at least the system won't crash. > > The tricky case, and the case that Vladimir is stuck on, is number 3. How > does the DRM know what the 2D X driver is going to do? Jens and Keith have > suggested using a new set of IOCTLs. By this I assume that he meant having > a new IOCTL number for an old IOCTL, and the new IOCTL would do the same > thing. Simply by using the new entry point the DRM would know that the > caller (i.e., the 2D X driver) is "new." Jens & Keith, is this what you > meant? If so, which IOCTL(s) would need "new" versions? > DRM_IOCTL_RADEON_CP_INIT? This is a possibility--but it might be easier to just have a new IOCTL in the manner you or Vladimir have suggested below. > Vladimir has suggested an alternative. Adding a new IOCTL so that the 2D X > driver would explicitly tell the DRM which version it is. I'm not sure that > I like this so much as presents to possibility for a whole new can of worms > in the future. Would it maybe better to add a new IOCTL to specifically say > "Hey, use the new style memory layout"? Either would work. Vladimir could reuse his versioning for other changes--but keeping track of what changes worked with which version would get confusing. Your suggestion is simple and might make maintenance easier. > So, when the 2D driver detects that the DRM is "new," it would use some form > of new IOCTL. The DRM would then know that the 2D driver is also "new," and > the DRM would perform the mapping accordingly. Otherwise, the 2D driver > detects the old DRM version and disables video capture support, or the DRM > gets the old IOCTL and performs the mapping the old way. Exactly. You could do this with Vladimir's IOCTL as well as long as the DRM assumes a base level version if the IOCTL is not used that identifies the old 2D driver. > Now, if all (or at least all the important parts) of the above is correct, > is there any reason why we should not move forward with this solution? At > first blush, there don't seem to be any horrible pitfalls, and I don't > really see any other way that will keep us out of trouble with Linus and > with our users. Ian, I like your suggestion--but we both have to keep in mind that Vladimir is doing the leg work on this one. If his solution is backwards compatible then I'd be inclined to go with what he and Kevin Martin and Marc La France work out. They are the ones currently maintaining the ATI driver code base. > There is (at least) one remaining issue. In the case where a user has the > new 2D part and wants to use video capture but doesn't have a new enough > DRM, how do we effectively inform them? I don't think that just logging a > message to the X log / syslog is good enough. Is there any other way? > Could we do something perverted like "capture" a screen of text that says > "You must upgrade your DRM to use video capture"? :) I would imagine the video capture API has error handling. I would recommend both logging the failure and returning an error code to the client. The client usually has the best ability to gracefully handle and report failures. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Vladimir Dergachev wrote: > As for Linus not wanting to accept it, 2.4 has dropped most nat filters > except for ftp and most of them aren't back yet. So I don't buy this > argument. Vladimir, This is no joke. We absolutely need compatability. Large amounts of developer pain don't even begin to compare to the enormous number of headaches incompatability causes our users. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
