On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
You assume wrongly that things must happen in the vertical blanking
period. Since the screen is traced from the top on monitors, all an
operation has to do to get a flickerfree update, is to not collide
with the screen tracing. F.ex. it could draw
On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
You assume wrongly that things must happen in the vertical blanking
period. Since the screen is traced from the top on monitors, all an
operation has to do to get a flickerfree update, is to not collide
with the screen tracing. F.ex. it could
On Mon, 2002-11-04 at 02:56, Mark Vojkovich wrote:
Is there an XFree86 module-aware version of gdb for Linux PPC
someplace?
I'm not aware of any binaries, but the patch for current gdb versions is
mostly architecture independent. I hope Mike will manage to get it
integrated into stock gdb
On Mon, Nov 04, 2002 at 08:39:10AM +0100, [EMAIL PROTECTED] wrote:
On Fri, Nov 01, 2002 at 10:41:33PM +0100, [EMAIL PROTECTED] wrote:
If one knew the time until vblank, one could simply wait that time,
and then do a xsync.
It could really be that simple.
You can't sleep
I think I have the answer, but I don't really like it :(
I ran 'xvinfo' and amongst the interesting things it returned, there was this
line:
maximum XvImage size: 1024 x 1024
I normally run at 1152x864, so when I dropped back to 1024x768, the lines
were MUCH reduced - I could still see
On Thu, Oct 17, 2002 at 07:10:25AM +, sjb wrote:
Apparatus wrote:
When using this driver (1.0.27) my system seems to hang and the screen
displays solid colorful lines like and emergency broadcast test on the
television. This occurs while using sdl (both 1.2.4 and 1.2.5) with a
video
Frank v Waveren wrote:
On Sun, Nov 03, 2002 at 07:11:35PM -0500, Kevin Brosius wrote:
Have you tried depth 16 and a larger mode, say 800x600? Not that depth
8 shouldn't work, but I'm curious. Also, does your XF86Config file
contain a 'set_mclk' parameter (or variant with mclk in it)?
Alan Hourihane wrote:
Can you try 1.0.28
Ooh .. looks good!
I've tried it with mplayer on a selection of mpegs and it didn't crash
which is a big improvement *8-)
I still see a line (or two) of wayward pixels that wrap around the
screen boundaries on *some* mpegs .. looks like a mixture of
sjb wrote:
I've tried it with mplayer on a selection of mpegs and it didn't crash
which is a big improvement *8-)
*bzzzt*
Sorry, it's just crashed again leaving the laptop hard locked and
displaying a rather fetching horizontally striped pattern on the LCD
panel 8-(
sjb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ sjb [EMAIL PROTECTED] was heard to say:
| Alan Hourihane wrote:
| Can you try 1.0.28
[...]
| I still see a line (or two) of wayward pixels that wrap around the
| screen boundaries on *some* mpegs .. looks like a mixture of overlay
| colours and
On Mon, Nov 04, 2002 at 02:32:02PM +, sjb wrote:
sjb wrote:
I've tried it with mplayer on a selection of mpegs and it didn't crash
which is a big improvement *8-)
*bzzzt*
Sorry, it's just crashed again leaving the laptop hard locked and
displaying a rather fetching horizontally
On Mon, Nov 04, 2002 at 09:46:18AM -0500, Norman Walsh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ sjb [EMAIL PROTECTED] was heard to say:
| Alan Hourihane wrote:
| Can you try 1.0.28
[...]
| I still see a line (or two) of wayward pixels that wrap around the
| screen
I would prefer OS drivers for reasons other than whether or not I plan
to hack on them. What I would really like a pointer to is a data base
of recent cards supported natively by X.
Thanks,
Harold Martin
On Sunday, November 3, 2002, at 02:48 PM, Georgina Economou wrote:
- Original Message
I'm wondering if there is a way to have two distinct X display
on two distinct graphic board (say one AGP, one PCI) managed
absolutely
independently one from the other : i.e. one xdm running for each
so that two sessions with two distinct users working at the same
time
with two
On Mon, Nov 04, 2002 at 09:06:05AM -0700, Harold Martin wrote:
I would prefer OS drivers for reasons other than whether or not I plan
to hack on them. What I would really like a pointer to is a data base
of recent cards supported natively by X.
http://www.xfree86.org/4.2.0/Status.html
Kurt
On Mon, Nov 04, 2002 at 08:38:35AM -0500, Kevin Brosius wrote:
Excellent. So as far as you can tell the Trio 64 3D works in 4.2.0? I
haven't had any reports about it for a while, so it's good to hear it's
okay.
Well, mode changing goes paired with ~10 seconds of the screen
switching quickling
At 10:26 AM 11/4/02, you wrote:
On Mon, Nov 04, 2002 at 09:06:05AM -0700, Harold Martin wrote:
I would prefer OS drivers for reasons other than whether or not I plan
to hack on them. What I would really like a pointer to is a data base
of recent cards supported natively by X.
Hi,
There's a problem when validating a given mode. The board I have has 256
megs and it fails crying that it has insufficient memory for the given
mode. This happens because the videoRam in bits is equal to 2^31 ( 256
megs). The number passes the numerical limit of an int. I believe
that
Title: RE: [Xpert]256 megs board fails Validation,
sorry, but your number theory has some error.
2^1 = 2 (1 bit, counting from 0 to 1 = 2 values)
2^2 = 4 (2 bits, counting from 0 to 3 = 4 values)
2^4 = 8 (3 bits counting from 0 to 7 = 8 values)
[...]
2^31 = 2 GB
2^32 = 4 GB
an integer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/ Alan Hourihane [EMAIL PROTECTED] was heard to say:
| Is this related only to playing mpegs, or might 1.0.28 actually
| improve the general wrap around problem seen on a number of LCD
| panels?
|
| What sized panel ?
|
| Have you tried
|
|
On Sun, 2002-11-03 at 22:26, Mark Vojkovich wrote:
On 3 Nov 2002, Mikkel Lauritsen wrote:
--- snip ---
As mentioned in RedHat bug 75018, Mike Harris has a new build from CVS
at ftp://people.redhat.com/mharris . This build fixes the nForce crash
but introduces a new bug where (at least)
On 4 Nov 2002, Mikkel Lauritsen wrote:
On Sun, 2002-11-03 at 22:26, Mark Vojkovich wrote:
On 3 Nov 2002, Mikkel Lauritsen wrote:
--- snip ---
As mentioned in RedHat bug 75018, Mike Harris has a new build from CVS
at ftp://people.redhat.com/mharris . This build fixes the nForce crash
I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits=
2147483648. The Xserver calculates the memory in bits when validating
the mode.
Luugi
Alexander Stohr wrote:
RE: [Xpert]256 megs board fails Validation,
sorry, but your number theory has some error.
2^1 = 2 (1
On Mon, 4 Nov 2002, Luugi Marsan wrote:
There's a problem when validating a given mode. The board I
have has 256
megs and it fails crying that it has insufficient memory for
the given
mode. This happens because the videoRam in bits is equal to
2^31 ( 256
megs). The number
Title: RE: [Xpert]256 megs board fails Validation,
and
thats with boards that can handle bus width with chunks of 256 bit = 32 byte per
access cylce.
i think i do generally object to using signed numbers for
ordinal values. ;-)
if
there is really a limitiation,
then its the question if
Hi All,
I'm a newbie to this list.
I'd appreciate if you gurus can help me reinstall Xfree86 by telling me
which RPMs I need to reinstall since I think my X-Windows in broken.
Thanks,
Peram
_
Protect your PC - get McAfee.com
Mikkel Lauritsen wrote:
On Sun, 2002-11-03 at 22:26, Mark Vojkovich wrote:
On 3 Nov 2002, Mikkel Lauritsen wrote:
--- snip ---
As mentioned in RedHat bug 75018, Mike Harris has a new build from CVS
at ftp://people.redhat.com/mharris . This build fixes the nForce crash
but introduces a new
Marc Aurele La France wrote:
On Mon, 4 Nov 2002, Luugi Marsan wrote:
There's a problem when validating a given mode. The board I
have has 256
megs and it fails crying that it has insufficient memory for
the given
mode. This happens because the videoRam in bits
On Mon, 4 Nov 2002, Luugi Marsan wrote:
I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits=
2147483648. The Xserver calculates the memory in bits when validating
the mode.
No, it doesn't. apertureSize is in bytes.
apertureSize is indeed in bytes, but in xf86Modes.c,
Title: RE: [Xpert]256 megs board fails Validation,
Hmm, looks like a limitation of the inital coders knowledge.
Nothing to worry about in an OpenSource project where lots
of coding youngsters did take part in.
The below coding:
if (mode-HDisplay * mode-VDisplay *
Why not use math?
factor = 1024 * 8 / scrp-fbFormat.bitsPerPixel;
if (mode-HDisplay * mode-VDisplay scrp-videoRam * factor)
return MODE_MEM;
This assumes that scrp-fbFormat.bitsPerPixel is a power of two.
Also, really huge monochrome displays are still vunerable. In
other words, I would
On Son, 2002-11-03 at 17:03, Aymeric Vincent wrote:
Michel Dänzer [EMAIL PROTECTED] writes:
It's also my impression that dualhead support shouldn't be hard to add
looking at the radeon driver. In fact, it might be doable without docs,
someone even posted a quick'n'dirty but untested
On Wed, Oct 30, 2002 at 07:46:35AM -0800, Ian Romanick wrote:
On Tue, Oct 29, 2002 at 11:29:05PM -0500, [EMAIL PROTECTED] wrote:
I confess I haven't researched this much (no googling), but a quick
search of the docs didn't reveal the answer, so I'll ask. Is there
a way to build XFree86
Title: RE: [Xpert]256 megs board fails Validation,
Adam Luter [mailto:[EMAIL PROTECTED]] wrote:
Why not use math?
factor = 1024 * 8 / scrp-fbFormat.bitsPerPixel;
if (mode-HDisplay * mode-VDisplay scrp-videoRam * factor)
return MODE_MEM;
This assumes that scrp-fbFormat.bitsPerPixel
that'd definitely depend on your code. afaik (conceptually) there's nothing
there that's specific to any kind of machine.
ricardo
At some point in the past you (Anurag Palsule [EMAIL PROTECTED]) said:
But will such an approach won't be portable across
different platforms, hardware and
Well you answered my question.
Isn't three going to be the only non-two factor? (Which in my previous
email, hadn't thought possible -- I thought 24bpp was treated as 32bpp).
Anyway the better way (if still doing factoring) is to use a loop like
this:
x = mode-HDisplay
y = mode-VDisplay
z =
- Original Message -
From: Sudhaker P [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 04, 2002 11:57 PM
Subject: [Xpert]Reinstalling XFree86
Hi All,
I'm a newbie to this list.
I'd appreciate if you gurus can help me reinstall Xfree86 by telling me
which RPMs I need to
I've implemented a simple configurable mode to control how many colors the
Render extension allocates on dynamic indexed visuals (pseudo/gray).
Here's the comment I wrote in the code:
/*
* For dynamic indexed visuals (GrayScale and PseudoColor), these control the
* selection of colors
Le mar 05/11/2002 à 07:05, Keith Packard a écrit :
I've implemented a simple configurable mode to control how many colors the
Render extension allocates on dynamic indexed visuals (pseudo/gray).
[...]
This policy is controlled by either a command line option (-render) or an
XF86Config
Hi
I have a Trio 3d vidoe card (4mb) and really really want to get a higher
resolution than 1024x768. I've just upgraded to XFree86 4.2.1.
The problem is that when I try to set a higher ersolution (16bpp) it
only draws a correct width at 1024. The rest (from 1025 to e.g. 1152) is
copied from
Ooops... forgot one file...
-Forwarded Message-
From: Jørn Christensen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: S3 Trio 3d
Date: 05 Nov 2002 08:52:44 +0100
Hi
I have a Trio 3d vidoe card (4mb) and really really want to get a higher
resolution than 1024x768. I've just
On Thu, Oct 31, 2002 at 06:13:12PM +, Alan Hourihane wrote:
On Thu, Oct 31, 2002 at 06:02:49PM +, Alan Hourihane wrote:
On Thu, Oct 31, 2002 at 06:53:35PM +0100, Michel Dänzer wrote:
On Don, 2002-10-31 at 18:38, Alan Hourihane wrote:
On Thu, Oct 31, 2002 at 01:30:32 +0100, Michel
42 matches
Mail list logo
