RE: Xrandr developer
Jim Gettys and Keith Packard are teh main protagonists, however Jim has been busy recuperating from a broken ankle, and Keith has been involved in some political stuff - see the 'forum' mailing for details. It seems the best thing to do at the moment is for those of us interested in XRandR development to get together, plan out some work, log bugs/features in bugzilla and then do some coding. I'm interested in making it work with xinerama, whats your interest? Rob Taylor -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Robert Woerle Paceblade/Support Sent: 27 March 2003 08:43 To: [EMAIL PROTECTED] Subject: Xrandr developer Hi who is maintaining the XRANR extension ??? i need contact since i want to enhance it Cheers Rob -- _ *Robert Woerle **Technical Support | Linux PaceBlade Technology Europe SA* phone:+49 89 552 99935 fax: +49 89 552 99910 mobile: +49 179 474 45 27 email:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] web: http://www.paceblade.com _ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xvideo patch for R128
[I didn't see anything specific for patches on
http://www.xfree86.org/mailman/listinfo (and I haven't been keeping
track of the recent list changes), so I hope this is ok to post here.]
Here is a patch against XFree86 4.3.0 (from the xf-4_3_0 cvs tag).
The problem is that at high screen resolutions (i.e., with a high
dot-clock), if the ECP divisor is set wrong, images displayed with the
XVideo extension have weird green noise in them (vertical green static
that appears to be over or between the pixels). Alternatively, if
the ECP divisor was somehow set correctly before XFree86 4.3.0 starts
(e.g., with Windows or GATOS), then the symptom is that only the left
half (or third) of the image is displayed when using Xvideo (because
h_inc is computed wrong).
Thanks, Rik Faith
Index: r128_reg.h
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/r128_reg.h,v
retrieving revision 1.15
diff -u -p -r1.15 r128_reg.h
--- r128_reg.h 2002/12/16 16:19:11 1.15
+++ r128_reg.h 2003/03/31 15:40:53
@@ -935,6 +935,7 @@
#define R128_TRAIL_X_SUB 0x1620
#define R128_VCLK_ECP_CNTL0x0008 /* PLL */
+# define R128_ECP_DIV_MASK (3 8)
#define R128_VENDOR_ID0x0f00 /* PCI */
#define R128_VGA_DDA_CONFIG 0x02e8
#define R128_VGA_DDA_ON_OFF 0x02ec
Index: r128_video.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/r128_video.c,v
retrieving revision 1.26
diff -u -p -r1.26 r128_video.c
--- r128_video.c2003/02/19 01:19:41 1.26
+++ r128_video.c2003/03/31 15:40:53
@@ -61,8 +61,21 @@ typedef struct {
CARD32videoStatus;
Time offTime;
Time freeTime;
+ int ecp_div;
} R128PortPrivRec, *R128PortPrivPtr;
+static void R128ECP(ScrnInfoPtr pScrn, R128PortPrivPtr pPriv)
+{
+R128InfoPtr info = R128PTR(pScrn);
+unsigned char *R128MMIO = info-MMIO;
+int dot_clock = info-ModeReg.dot_clock_freq;
+
+if (dot_clock 12500) pPriv-ecp_div = 0;
+else if (dot_clock 25000) pPriv-ecp_div = 1;
+elsepPriv-ecp_div = 2;
+
+OUTPLLP(pScrn, R128_VCLK_ECP_CNTL, pPriv-ecp_div8, ~R128_ECP_DIV_MASK);
+}
void R128InitVideo(ScreenPtr pScreen)
{
@@ -196,6 +209,7 @@ R128AllocAdaptor(ScrnInfoPtr pScrn)
pPriv-brightness = 0;
pPriv-saturation = 16;
pPriv-currentBuffer = 0;
+R128ECP(pScrn, pPriv);
return adapt;
}
@@ -728,12 +742,15 @@ R128DisplayVideo422(
){
R128InfoPtr info = R128PTR(pScrn);
unsigned char *R128MMIO = info-MMIO;
+R128PortPrivPtr pPriv = info-adaptor-pPortPrivates[0].ptr;
int v_inc, h_inc, step_by, tmp;
int p1_h_accum_init, p23_h_accum_init;
int p1_v_accum_init;
+R128ECP(pScrn, pPriv);
+
v_inc = (src_h 20) / drw_h;
-h_inc = (src_w 12) / drw_w;
+h_inc = (src_w (12 + pPriv-ecp_div)) / drw_w;
step_by = 1;
while(h_inc = (2 12)) {
@@ -799,12 +816,13 @@ R128DisplayVideo420(
){
R128InfoPtr info = R128PTR(pScrn);
unsigned char *R128MMIO = info-MMIO;
+R128PortPrivPtr pPriv = info-adaptor-pPortPrivates[0].ptr;
int v_inc, h_inc, step_by, tmp, leftUV;
int p1_h_accum_init, p23_h_accum_init;
int p1_v_accum_init, p23_v_accum_init;
v_inc = (src_h 20) / drw_h;
-h_inc = (src_w 12) / drw_w;
+h_inc = (src_w (12 + pPriv-ecp_div)) / drw_w;
step_by = 1;
while(h_inc = (2 12)) {
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Make install blows away startup files?
Kevin Brosius [EMAIL PROTECTED] wrote: Depends somewhat on how RH does X init. You can look through startx and xinit setup and see what's being changed. Isn't the installer supposed to not replace xinit.rc if the file already exists? That is what the comment in the xf86site.def file says, but that would appear not to be the case? I know on SuSE that 'make install' breaks the KDM/xdm startup, and that they use a WINDOWMANAGER environment variable in their X init pieces. If you don't have that variable set, then you'll get either no wm or twm. But doing a source install over your distro's install tree is really up to you to resolve. Granted, but since XFree86 appears to be starved for developers and testers, don't you think it would be a good idea to make it painless for testers to do a full build and install *without* blowing away their current system configuration? Might make more people willing to test XFree86 releases on their machines. One experience like I had for the average tester who just wants to help out is likely to cause him to re- install his Linux distro and never run a 'make install' again ;-) Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Help with configuration please!
I stripped forum from the reply since devel is more appropriate. The reason why this doesn't work reliably in the nv driver is because there is not an I2C bus - there are THREE of them - and it's not clear which one the driver should be looking on. They're not even the same between one card and the next since different board vendors can lay the cards out differently. If I know the correct bus, detection of the flat panel is trivial. I am looking into this problem, but I'm not familiar with XFree86's DDC code, and haven't found someone who is. Mark. On Mon, 31 Mar 2003, Sven Luther wrote: On Sun, Mar 30, 2003 at 04:41:58PM -0500, Mark Vojkovich wrote: The nv driver has trouble autodetecting flat panels on dual head cards. It can help to add: I guess it is not only the nv driver. BTW, should this flatpanel detection not be done in a common function, like we have the mode calculation one ? After all, it will be the same kind of code for all the drivers once the drivers provide access to a DDC bus, isn't it ? Friendly, Sven Luther ___ Forum mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/forum ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Help with configuration please!
On Mon, 31 Mar 2003, Mark Vojkovich wrote: I stripped forum from the reply since devel is more appropriate. The reason why this doesn't work reliably in the nv driver is because there is not an I2C bus - there are THREE of them - and it's not clear which one the driver should be looking on. They're not even the same between one card and the next since different board vendors can lay the cards out differently. If I know the correct bus, detection of the flat panel is trivial. I am looking into this problem, but I'm not familiar with XFree86's DDC code, and haven't found someone who is. I gave Egbert a hand with it, but I suspect that you are as familar with it as I am. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Help with configuration please!
On Mon, 31 Mar 2003, Andrew C Aitchison wrote: On Mon, 31 Mar 2003, Mark Vojkovich wrote: I stripped forum from the reply since devel is more appropriate. The reason why this doesn't work reliably in the nv driver is because there is not an I2C bus - there are THREE of them - and it's not clear which one the driver should be looking on. They're not even the same between one card and the next since different board vendors can lay the cards out differently. If I know the correct bus, detection of the flat panel is trivial. I am looking into this problem, but I'm not familiar with XFree86's DDC code, and haven't found someone who is. I gave Egbert a hand with it, but I suspect that you are as familar with it as I am. I know hardly anything about it. I believe the current DDC support in the nv driver was added by Egbert. I asked Egbert and he didn't answer so I assumed he didn't know the answers to my questions. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Creating an XImage
I am trying to create an XImage, but after the function call to XCreateImage(), my XImage pointer's value is 0. I really don't know much about Xlib. I want to create an XImage for image data that I already have. Can someone give me a list of steps to follow that lead to a properly created XImage? I am currently getting the WindowAttributes from the root window and passing its Visual* to the XCreateImage() function, while guessing at some of the other values. The image data that I have is for a 24-bit image. I assume that I should put the data into a contiguous char array. Below is the relevant portion of my code... -- const int DEPTH = 24; const int WIDTH = 100; const int HEIGHT = 100; const int FORMAT = ZPixmap; const int OFFSET = 0; const int BITMAP_PAD = 0; const int BYTES_PER_LINE = (WIDTH * 3); const int IMAGE_BYTES = WIDTH * HEIGHT * 3; XWindowAttributes* rootWindowAttributes = new XWindowAttributes; Visual* visual = rootWindowAttributes-visual; char* data = new char[IMAGE_BYTES]; XImage* xImage = XCreateImage(display, visual, DEPTH, FORMAT, OFFSET, data, WIDTH, HEIGHT, BITMAP_PAD, BYTES_PER_LINE); -- Josh Davis _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
error building shared libXau
I am trying to enable building shared lib for libXau, but got an error: ... gcc -o ./libXau.so.6.0~ -shared -Wl,-rpath,/usr/X11R6/lib -Wl,-soname,libXau.so.6 AuDispose.o AuFileName.o AuGetAddr.o AuGetBest.o AuLock.o AuRead.o AuUnlock.o AuWrite.o + rm -f libXau.so.6 + ln -s libXau.so.6.0 libXau.so.6 + rm -f ../../exports/lib/libXau.so.6 + cd ../../exports/lib /bin/sh: cd: /home/fliu/src/x/xc/exports/lib - No such file or directory apparently nobody created the directory ../../exports/lib I am wondering why I didn't get this error for building other shared libs such as those default libs that have shared enabled? Any ideas? Frank ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
shared Xfontcache
I am trying to enabl shared Xfontcache, but xfs fails to link: ... gcc -o xfs -O2 -L../../exports/libdifs/libdifs.a difs/libdifs.a os/libos.a -L/usr/X11R6/lib -lsocket -L../../exports/lib -lXfont -lfntstubs -lfreetype -lXfontcache -lm -lz -lsocket -Wl,-rpath,/usr/X11R6/lib ../../exports/lib/libXfontcache.so: undefined reference to `XextAddDisplay' ../../exports/lib/libXfontcache.so: undefined reference to `XextFindDisplay' ../../exports/lib/libXfontcache.so: undefined reference to `_XReply' ../../exports/lib/libXfontcache.so: undefined reference to `XextCreateExtension'../../exports/lib/libXfontcache.so: undefined reference to `_XFlush' ../../exports/lib/libXfontcache.so: undefined reference to `XextRemoveDisplay' ../../exports/lib/libXfontcache.so: undefined reference to `XMissingExtension' I guess I need something like #define SharedXfontcacheReqs $(LDPRELIB) $(EXTENSIONLIB) $(XLIB) in my library.tmpl file??? btw, I am testing to build all libaries in shared. It seems no one has done this test yet. Any gottas? Any other Shared...Reqs that you know are missing? Thanks! Frank ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Make install blows away startup files?
Matthieu Herrb [EMAIL PROTECTED] wrote: Might make more people willing to test XFree86 releases on their machines. One experience like I had for the average tester who just wants to help out is likely to cause him to re- install his Linux distro and never run a 'make install' again ;-) We all agree. But problems can't be fixed only by complaining. Could you send us lists of files (with sizes or modification dates) and symlinks in /etc/X11 before (that is the clean RH installer result) and after 'make install' on a RH system ? That would probably help finding what's wrong. Sure, I have the original untouched directory now and I can copy it and redo a make install and see if I can find the differences. I suppose I could run a diff between the original files and the modified files and post the diff here. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Make install blows away startup files?
Kendall Bennett wrote: Kevin Brosius [EMAIL PROTECTED] wrote: Depends somewhat on how RH does X init. You can look through startx and xinit setup and see what's being changed. Isn't the installer supposed to not replace xinit.rc if the file already exists? That is what the comment in the xf86site.def file says, but that would appear not to be the case? Well, /etc/X11/xinit/xinitrc certainly wasn't updated during my last 'make install'. Assuming you logged the install, you'll be able to tell exactly what was written. Mine has the following: - make[3]: Entering directory `/usr/local/src/xc-cvs/xc/programs/xinit' install -c xinit /usr/X11R6/bin/xinit install -c -m 0755 startx /usr/X11R6/bin/startx Not overwriting existing /usr/X11R6/lib/X11/xinit/xinitrc install in programs/xinit done -- -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Creating an XImage
On Tue, 1 Apr 2003, Carsten Haitzler wrote:
On Mon, 31 Mar 2003 17:13:58 -0500 Josh Davis [EMAIL PROTECTED] babbled:
I am trying to create an XImage, but after the function call to
XCreateImage(), my XImage pointer's value is 0. I really don't know much
about Xlib. I want to create an XImage for image data that I already have.
Can someone give me a list of steps to follow that lead to a properly
created XImage?
I am currently getting the WindowAttributes from the root window and passing
its Visual* to the XCreateImage() function, while guessing at some of the
other values. The image data that I have is for a 24-bit image. I assume
that I should put the data into a contiguous char array. Below is the
relevant portion of my code...
--
const int DEPTH = 24;
try DEPTH=32 (24 isn't really allowed)
Careful Carsten. Don't mix up your terminology.
You can create an Ximage in any depth the server supports:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
The point is that depth != bitsPerPixel. If you're going
to Put an XImage into a Window, the depths of the Window and
XImage must match, and since there aren't any depth 32 Windows,
he most certainly wants a depth 24 XImage. But according to
the pixmap formats, depth 24 is 32 bits per pixel.
Mark.
const int WIDTH = 100;
const int HEIGHT = 100;
const int FORMAT = ZPixmap;
const int OFFSET = 0;
const int BITMAP_PAD = 0;
const int BYTES_PER_LINE = (WIDTH * 3);
try this:
XImage *
my_new_ximage(Display *display, Visual *visual, int width, int height, void
*data)
{
/* this creates an ximage of the same depth as the specified visual */
/* NOTE: Ximages must have pixels aligned to 8, 16 or 32bit boundaries. */
/* 24bit (ie 3 bytes per pixel) is not valid and must be padded out to 32 */
/* bits per pixel (4 bytes). The red, greeb and blue masks for your visual */
/* will let you know what parst of the pixel are used for which color or */
/* are padding. You really should use XPutPixel(ximage, x, y, value); to */
/* set pixels if you want to not have portability problems. */
/* If you don't you need to be VERY careful how you address the data of */
/* the XImage *./
XImage *ximage;
XVisualInfo visualinfo, *visualinfo_return;
int number_return;
if ((width 1) || (height 1) || (!display) || (!visual)) return NULL;
visualinfo.visualid = visual-visualid;
visualinfo_return = XGetVisualInfo(display, VisualIDMask, visualid,
number_return);
/* no pointer return. abort */
if (!visualinfo_return) return NULL;
/* should only return 1 visual with that id */
if (number_return != 1) return NULL;
ximage = XCreateImage(display, visual, visualinfo_return[0].depth, ZPixmap,
data, width, height, 32, 0);
return ximage;
}
read the comments above. you can't do what you are doing as XImages cant be
24bit. you will have to either work with your data in 32 bit or have a 24bit to
32 bit converter. Also note that if you aren't running 32bpp (or 24bpp) you
can't just make 32bit XImages and have X do the color conversion fro you - you
need to handle each bit depth yourself. So if the server is running 16bpp or
15bpp or 8bpp or even monochrome this will simply not work. This is why there
are many libraries and toolkits that handle this work for you.
Several:
Imlib2
SDL
GTK+ (Gdk)
Qt
and others... I'll leave it to you to do the research, or do the hard work all
yourself. :)
const int IMAGE_BYTES = WIDTH * HEIGHT * 3;
XWindowAttributes* rootWindowAttributes = new XWindowAttributes;
Visual* visual = rootWindowAttributes-visual;
char* data = new char[IMAGE_BYTES];
XImage* xImage = XCreateImage(display,
visual,
DEPTH,
FORMAT,
OFFSET,
data,
WIDTH,
HEIGHT,
BITMAP_PAD,
BYTES_PER_LINE);
--
Josh Davis
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
--
--- Codito, ergo sum - I code, therefore I
Re: Make install blows away startup files?
Kevin Brosius [EMAIL PROTECTED] wrote: Isn't the installer supposed to not replace xinit.rc if the file already exists? That is what the comment in the xf86site.def file says, but that would appear not to be the case? Well, /etc/X11/xinit/xinitrc certainly wasn't updated during my last 'make install'. Assuming you logged the install, you'll be able to tell exactly what was written. Mine has the following: Yes, I did log the install and I will look at it soon. However I just did an install with the three options to specifically not update the config files and it still has the problem. So it is not something related to those options but something else on Red Hat that is getting blown away during the install. I will re-do the 4.3.0 install from scratch and diff the /etc/X11 directories to see what changed, but I won't be able to do that till next week as I am leaving on vacation Wednesday (until Tuesday next week ;-). Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Creating an XImage
On Mon, 31 Mar 2003 20:26:47 -0500 (EST) Mark Vojkovich [EMAIL PROTECTED]
babbled:
On Tue, 1 Apr 2003, Carsten Haitzler wrote:
On Mon, 31 Mar 2003 17:13:58 -0500 Josh Davis [EMAIL PROTECTED]
babbled:
I am trying to create an XImage, but after the function call to
XCreateImage(), my XImage pointer's value is 0. I really don't know much
about Xlib. I want to create an XImage for image data that I already
have.
Can someone give me a list of steps to follow that lead to a properly
created XImage?
I am currently getting the WindowAttributes from the root window and
passing its Visual* to the XCreateImage() function, while guessing at some
of the other values. The image data that I have is for a 24-bit image. I
assume that I should put the data into a contiguous char array. Below is
the relevant portion of my code...
--
const int DEPTH = 24;
try DEPTH=32 (24 isn't really allowed)
Careful Carsten. Don't mix up your terminology.
true... but the pixels will still be padded out to 32bpp in the ximage :)
You can create an Ximage in any depth the server supports:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
The point is that depth != bitsPerPixel. If you're going
to Put an XImage into a Window, the depths of the Window and
XImage must match, and since there aren't any depth 32 Windows,
he most certainly wants a depth 24 XImage. But according to
the pixmap formats, depth 24 is 32 bits per pixel.
thats what i was getting at :)
Mark.
const int WIDTH = 100;
const int HEIGHT = 100;
const int FORMAT = ZPixmap;
const int OFFSET = 0;
const int BITMAP_PAD = 0;
const int BYTES_PER_LINE = (WIDTH * 3);
try this:
XImage *
my_new_ximage(Display *display, Visual *visual, int width, int height, void
*data)
{
/* this creates an ximage of the same depth as the specified visual */
/* NOTE: Ximages must have pixels aligned to 8, 16 or 32bit boundaries. */
/* 24bit (ie 3 bytes per pixel) is not valid and must be padded out to 32
*//* bits per pixel (4 bytes). The red, greeb and blue masks for your
visual *//* will let you know what parst of the pixel are used for which
color or *//* are padding. You really should use XPutPixel(ximage, x, y,
value); to *//* set pixels if you want to not have portability problems.
*//* If you don't you need to be VERY careful how you address the data of
*//* the XImage *./
XImage *ximage;
XVisualInfo visualinfo, *visualinfo_return;
int number_return;
if ((width 1) || (height 1) || (!display) || (!visual)) return NULL;
visualinfo.visualid = visual-visualid;
visualinfo_return = XGetVisualInfo(display, VisualIDMask, visualid,
number_return);
/* no pointer return. abort */
if (!visualinfo_return) return NULL;
/* should only return 1 visual with that id */
if (number_return != 1) return NULL;
ximage = XCreateImage(display, visual, visualinfo_return[0].depth,
ZPixmap,
data, width, height, 32, 0);
return ximage;
}
read the comments above. you can't do what you are doing as XImages cant be
24bit. you will have to either work with your data in 32 bit or have a 24bit
to 32 bit converter. Also note that if you aren't running 32bpp (or 24bpp)
you can't just make 32bit XImages and have X do the color conversion fro you
- you need to handle each bit depth yourself. So if the server is running
16bpp or 15bpp or 8bpp or even monochrome this will simply not work. This is
why there are many libraries and toolkits that handle this work for you.
Several:
Imlib2
SDL
GTK+ (Gdk)
Qt
and others... I'll leave it to you to do the research, or do the hard work
all yourself. :)
const int IMAGE_BYTES = WIDTH * HEIGHT * 3;
XWindowAttributes* rootWindowAttributes = new XWindowAttributes;
Visual* visual = rootWindowAttributes-visual;
char* data = new char[IMAGE_BYTES];
XImage* xImage = XCreateImage(display,
visual,
DEPTH,
FORMAT,
OFFSET,
data,
WIDTH,
HEIGHT,
BITMAP_PAD,
BYTES_PER_LINE);
--
Josh Davis
_
BuildGlxExt
Can somebody explain to me what is BuildGlxExt? in the comment, it says: /* * If you don't want to build support for an external GLX server module or * library, uncomment this. * #define BuildGlxExt NO */ what does external mean? Thanks! Frank ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Help with configuration please!
On Mon, Mar 31, 2003 at 03:34:43PM -0500, Mark Vojkovich wrote: I stripped forum from the reply since devel is more appropriate. Ok, no problem with me. The reason why this doesn't work reliably in the nv driver is because there is not an I2C bus - there are THREE of them - and it's not clear which one the driver should be looking on. They're not One for each head ans one for the video port ? even the same between one card and the next since different board vendors can lay the cards out differently. If I know the correct bus, detection of the flat panel is trivial. This is a problem because you don't have full documentation, isn't it ? I am looking into this problem, but I'm not familiar with XFree86's DDC code, and haven't found someone who is. This is probably because nobody really is, and because the DDC code is not really used right now. The standard open source reply is : you are interested in this ? you just have become the official expert on it. :) Anyway, the way i see it is that each driver should provide a DDC/I2C bus reading functions, which already exist, altough if i take example on the glint driver, it is filled at the end of PreInit, which is a bit late. Then, maybe before or during xf86ValidateModes, you would also call some monitor code, which would read information about the attached monitor of each head, and use the information to limit the possible available monitor modes, with a possibility to override this from the configuration file, if need be. Currently, at least for the glint driver, the DDC/I2C info is read at ModeInit time, which is too late to do anything apart print the result of the edid read. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: error building shared libXau
Frank Liu wrote (in a message from Monday 31) I am trying to enable building shared lib for libXau, but got an error: ... gcc -o ./libXau.so.6.0~ -shared -Wl,-rpath,/usr/X11R6/lib -Wl,-soname,libXau.so.6 AuDispose.o AuFileName.o AuGetAddr.o AuGetBest.o AuLock.o AuRead.o AuUnlock.o AuWrite.o + rm -f libXau.so.6 + ln -s libXau.so.6.0 libXau.so.6 + rm -f ../../exports/lib/libXau.so.6 + cd ../../exports/lib /bin/sh: cd: /home/fliu/src/x/xc/exports/lib - No such file or directory apparently nobody created the directory ../../exports/lib I am wondering why I didn't get this error for building other shared libs such as those default libs that have shared enabled? Any ideas? Looks like a bug in many *lib.rules configuration files. The LinkBuildSonameLibrary() macro doesn't build the export/lib directory first. (The LinkBuildLibrary() macro used by non-shared libs does). It currently works with other shared libraries because the 1st built library is precisely libXau and its normally built non-shared only, so its build rule will indeed create the export/lib directory. If the 1st built library is shared and since the shared target appears 1st in Library.tmpl, the directory isn't created. This should be fixed. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
