Hi Friends,
I am a bit confused ... I understand, if i crosscompiple(Xipaq) When we do "make
World" (I mean only the order of files)::
host.def -> linux.cf -> kdrive.cf -> {xitsy.cf|tinyX.cf ; cross.def}
The file iPAQH3600.cf says define KDriveServer and XiPAQH3500Server in host.def, but
th
There's a report in bugzilla from Ed Fardos about problems that can happen
if DPMS is enabled (with xset) while the screen isn't blanked.
I can think of several ways to handle this. One is to force screen
blanking everwhere DPMSSet(level) with level != DPMSModeOn is
called. However, the easiest
On Mon, 10 Nov 2003, Ricardo A. Baratto wrote:
> hi all,
> is there any way to extract the XRectangles that make up a Region in Xlib?
>
> xlib ref doesn't mention anything to that effect.
>
> thanks,
> ricardo
>
I don't see such a function. The Region is deliberately
opaque too. You can s
ok... i should give up. that was it.
I've been using Xlib for a few years now, and i've just learn that XSync
and XFlush are actually very different.
Thank you for your help, sorry for the noise...
Pierre
Mark Vojkovich wrote:
XGetImage didn't generate the error, XCreatePixmap did.
You are f
hi all,
is there any way to extract the XRectangles that make up a Region in Xlib?
xlib ref doesn't mention anything to that effect.
thanks,
ricardo
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
OK - thanks
I'll have to try that on Friday (I won't be home before...) and will
post the results.
- Salvio
Marc Aurele La France wrote:
On Mon, 10 Nov 2003, Salvio wrote:
If `top` shows that the server is not entirely to blame for the CPU load,
see if turning on backing store has any effe
On Mon, Nov 10, 2003 at 11:36:54AM -0800, Alan Coopersmith wrote:
>David Dawes wrote:
>> I've noticed that the reference to in6addr_any in xtrans has broken
>> libICE.so compatibility, at least on FreeBSD 4.3. This shows up a
>> runtime loader error when attempting to run applications built agains
On Mon, 10 Nov 2003, Salvio wrote:
> >>If `top` shows that the server is not entirely to blame for the CPU load,
> >>see if turning on backing store has any effect.
> CPU is idle - CPU is maxed out when moving windows
> swap memory is not used
> less than 50% of available phisical memory is used
David Dawes wrote:
I've noticed that the reference to in6addr_any in xtrans has broken
libICE.so compatibility, at least on FreeBSD 4.3. This shows up a
runtime loader error when attempting to run applications built against
an older version of the library:
/usr/libexec/ld-elf.so.1: /usr/X11R6/lib/
I've noticed that the reference to in6addr_any in xtrans has broken
libICE.so compatibility, at least on FreeBSD 4.3. This shows up a
runtime loader error when attempting to run applications built against
an older version of the library:
/usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libICE.so.6: Undef
Marc,
If `top` shows that the server is not entirely to blame for the CPU load,
see if turning on backing store has any effect.
CPU is idle - CPU is maxed out when moving windows
swap memory is not used
less than 50% of available phisical memory is used
(both when moving and when not moving window
On Mon, 2003-11-10 at 07:59, Juliusz Chroboczek wrote:
> >> server is now 866KB, which is still a wee bit over what I'd expect.]
>
> DD> I got about that for an IA32 build.
>
> So am I. Something happened, I used to get almost 100KB less than that.
>
> Unfortunately, I won't have time to track
Frank Gießler wrote:
with my current CVS snapshot (Changelog up to #530), glxgears gives me
the following at startup:
X Error of failed request: BadLength (poly request too large or
internal Xlib length error)
Major opcode of failed request: 144 (GLX)
Minor opcode of failed request: 1 (X_
On Mon, 10 Nov 2003, Salvio wrote:
> >>>Everything starts fine with no errors (as you can see from the logs).
> >>>The problem I have is that I don't think I have 2D acceleration.
> >>>The simple test I do is to just drag a window on the screen... the
> >>>redraw is extremely slow and the CPU is
Hi all,
with my current CVS snapshot (Changelog up to #530), glxgears gives me the following at startup:
X Error of failed request: BadLength (poly request too large or internal Xlib length
error)
Major opcode of failed request: 144 (GLX)
Minor opcode of failed request: 1 (X_GLXRender)
As I said, the CPU is normally idle. When I quickly drag windows on the
screen using my mouse, the CPU gets maxed out.
I cannot believe that the redraw speed is that slow regardless of themes
and such: I can see the windows being actually redrawn on screen when
I drag them around the screen.
FYI: I
I recenly wrote a patch (with some help from Andreas) to a allow for
gamma adjustment of the video overlay. It adds the XV_GAMMA attribute.
The current patch works, but I'm not sure I'm programming the registers
right. Could someone with databooks verify how they should be
programmed? The releva
I agree with you that symbolic names are better in just about all
respects. I'm just saying that the nv driver is not the only one that
doesn't do it. That's it for me.
Alex
--- "Mike A. Harris" <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Nov 2003, Alex Deucher wrote:
>
> >Date: Mon, 10 Nov 2003 0
On Mon, Nov 10, 2003 at 06:38:24AM -0800, Alex Deucher wrote:
> Sorry I haven't looked at the glint driver in a while. I was just
> trying to make a point that lots of drivers out there use hex rather
> than symbolic names. I seemed to recall glint as being one of them,
> but I guess I was wrong.
On Mon, 10 Nov 2003, Alex Deucher wrote:
>Date: Mon, 10 Nov 2003 06:38:24 -0800 (PST)
>From: Alex Deucher <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: "nv" driver obscurities...
>
>Sorry I haven't looked at the gl
Some time ago, there was a chap in New Zealand who was attempting to reverse
engineer and documaent what all the nvidia registers did, -plus get DMA going
for various ops. Google may turn up something - I don't have a URL to hand.
The last I heard came from a couple of years back however.
Sorry I haven't looked at the glint driver in a while. I was just
trying to make a point that lots of drivers out there use hex rather
than symbolic names. I seemed to recall glint as being one of them,
but I guess I was wrong.
Alex
--- Sven Luther <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 09, 2
>> server is now 866KB, which is still a wee bit over what I'd expect.]
DD> I got about that for an IA32 build.
So am I. Something happened, I used to get almost 100KB less than that.
Unfortunately, I won't have time to track it down anytime soon.
Anyone have time to try out Keith's tree on htt
On Sun, 9 Nov 2003, Alex Deucher wrote:
>I agree that with hex values the driver is much harder to read
>and debug (as a casual developer). that's part of the reason
>the radeon driver is so well developed and feature-rich.
>however, I'd say that most drivers in xfree86 use hex values
>rather t
On Sun, Nov 09, 2003 at 11:23:38AM -0800, Alex Deucher wrote:
> I agree that with hex values the driver is much harder to read and
> debug (as a casual developer). that's part of the reason the radeon
> driver is so well developed and feature-rich. however, I'd say that
> most drivers in xfree86
25 matches
Mail list logo