On Sul, 2004-05-09 at 14:32, Jon Smirl wrote:
> I would like to see a single device drver always controlling the GPU and
> VRAM/AGP memory management. Then it is easy to switch graphics contexts on VT
> swap.
VRAM/AGP most of the time can probably be a generic library but yes I
agree, and at time
On Sul, 2004-05-09 at 22:42, Holger Waechtler wrote:
> don't know whether the imagination of a register-controlled graphics
> peripheral with hundrets of control registers is still valid for a fully
> programmable modern GPU.
Its true for older and low end ones though, and they still look that
w
Ian Romanick wrote:
Holger Waechtler wrote:
Jon Smirl wrote:
Sharing graphics contexts is not the same thing as allowing two
completely
different device drivers access to the hardware on VT swap. Two
different device
drivers may have completely different contents in all of the
registers, CP
ru
On Sun, May 09, 2004 at 08:14:59PM -0700, Ian Romanick wrote:
| ... I very seriously doubt that you can halt and restart an
| in-progress shader. That would require extra logic, reduce performance,
| and wouldn't help games. What makes you think any of the current cards
| are designed
Holger Waechtler wrote:
Jon Smirl wrote:
Sharing graphics contexts is not the same thing as allowing two
completely
different device drivers access to the hardware on VT swap. Two
different device
drivers may have completely different contents in all of the
registers, CP
running or not, VRAM an
Jon Smirl wrote:
Sharing graphics contexts is not the same thing as allowing two completely
different device drivers access to the hardware on VT swap. Two different device
drivers may have completely different contents in all of the registers, CP
running or not, VRAM and AGP space. With two device
Alan Cox wrote:
On Iau, 2004-05-06 at 20:57, Jon Smirl wrote:
Simple example, DRM starts GPU coprocessor running. VT swap happens. New user
stops coprocessor. VT swap back to DRM. Now DRM thinks it left the coprocessor
running but that's not true now. DRM and FB conflict when FB is using the
copro
Sharing graphics contexts is not the same thing as allowing two completely
different device drivers access to the hardware on VT swap. Two different device
drivers may have completely different contents in all of the registers, CP
running or not, VRAM and AGP space. With two device drivers you have
Around 17 o'clock on May 8, Alan Cox wrote:
> FB already has mode switch context waits, so does DRM. And you don't
> want to break direct access to registers for most things because its
> a performance consideration of high importance.
Direct access to device registers from user mode really isn'
On Iau, 2004-05-06 at 20:57, Jon Smirl wrote:
> Simple example, DRM starts GPU coprocessor running. VT swap happens. New user
> stops coprocessor. VT swap back to DRM. Now DRM thinks it left the coprocessor
> running but that's not true now. DRM and FB conflict when FB is using the
> coprocessor fo
On Iau, 2004-05-06 at 18:57, Jens Owen wrote:
> If mmapping is okay, then we're still able to touch hardware from user
> space drivers. I'm fine with that.
Basically the kernel needs to know you are working with the frame
buffer, and it needs to be able to revoke that from under you on a
hot un
--- Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> As far as acceleration - either 2d or 3d - it makes sense for it to stay
> in userspace.
X and everything else needs to stop mapping the registers to user space and
instead start using an IOCTL interface to a driver. The problem is that X or
what
On Thu, 6 May 2004, Martin Spott wrote:
> Vladimir Dergachev wrote:
>
> > Also, I would venture an opinion that, at the moment, the only Unices we
> > care about is Linux, BSD and Hurd - all open source. The current design
> > of XFree86 (with everything done in userspace) was motivated by the
On Thu, 6 May 2004, Keith Whitwell wrote:
> Jon Smirl wrote:
> > --- Jens Owen <[EMAIL PROTECTED]> wrote:
> >
> >>Six years ago, most devices could not handle this type of restriction
> >>efficiently. Things have improved on the high end; but the low end
> >>devices, are still very similar to w
Martin Spott wrote:
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
to support commercial Unices (li
Vladimir Dergachev wrote:
> Also, I would venture an opinion that, at the moment, the only Unices we
> care about is Linux, BSD and Hurd - all open source. The current design
> of XFree86 (with everything done in userspace) was motivated by the need
> to support commercial Unices (like Solaris or
Jon Smirl wrote:
--- Jens Owen <[EMAIL PROTECTED]> wrote:
Six years ago, most devices could not handle this type of restriction
efficiently. Things have improved on the high end; but the low end
devices, are still very similar to what we had back in the day. Even
today, I would be very cautio
Jon Smirl wrote:
Framebuffer access follows the rules; kernel calls are used to map it into user
space. The major violations in X are in PCI bus and graphics chip probing.
If mmapping is okay, then we're still able to touch hardware from user
space drivers. I'm fine with that.
I don't see any p
--- Jens Owen <[EMAIL PROTECTED]> wrote:
> Six years ago, most devices could not handle this type of restriction
> efficiently. Things have improved on the high end; but the low end
> devices, are still very similar to what we had back in the day. Even
> today, I would be very cautious of depl
Around 9 o'clock on May 6, Jens Owen wrote:
> If you would like to get a flavor for the issue I'm writing about, simply
> unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I
> think you'll find many difficult issues crop up related to software fall
> backs and efficient readb
John,
You can think of me as "Old School", and take my feedback in that
context. My main reason for participating in this discussion is to give
some historical perspective.
Jon Smirl wrote:
--- Jens Owen <[EMAIL PROTECTED]> wrote:
2) We wanted the bare minimum services in the kernel layer f
On Thu, 6 May 2004, Jon Smirl wrote:
> --- Jens Owen <[EMAIL PROTECTED]> wrote:
> >2) We wanted the bare minimum services in the kernel layer for
> > efficient and fast graphics support, and felt as much of the
> > driver code as possible should stay in user space.
>
> Linux kern
--- Jens Owen <[EMAIL PROTECTED]> wrote:
>2) We wanted the bare minimum services in the kernel layer for
> efficient and fast graphics support, and felt as much of the
> driver code as possible should stay in user space.
Linux kernel people are strongly in favor of changing Xfree t
Jon,
This issue of whether or not to use kgi goes all the way back to design
decisions we made in 1998. Based on my recollection, I believe these
were the top issues:
1) kgi was Linux specific. We needed a kernel level module that was
more portable.
2) We wanted the bare minimum serv
Another request is that this work be compared to the kgi work so that we don't
repeat the same mistakes. I wasn't around for that debate, can someone explain
what was learned from attempt?
I'll start reworking the proposal to include the feedback I have so far and get
it ready for the next round.
why do I get the impression we are discussing kgi or at least the goals of
kgi? without mentioning it ..is kgi a bad word around these parts? :-)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
Dieter Nützel wrote:
Litle rejection on latest Mesa CVS:
src/mesa/main/texcompress_s3tc.c.rej
You're right, here's a new patch. Nothing changed at all, except it
applies again...
Roland
mesa_r200_radeon_txc_cvs040504.diff.gz
Description: Unix tar archive
I've committed a new driver to src/mesa/drivers/dri/x11. It's basically a
pure-fallback driver like drivers/dri/fb, only it uses X's GLX instead of
miniglx. It's not done yet but it's good enough to get direct rendering: Yes
and run GL programs (they won't draw anything though).
What's the po
Here's a new version of the texture compression patch.
Changes:
- Thanks to Brian's changes all (core mesa) changes are now in only one
file (texcompress_s3tc.c), except one boolean variable.
- the texel fetch code works again (not sure why it didn't work last time)
- some small cleanups in the l
Thomas Hellstrom wrote:
Here is were the problem starts. All X side drivers are expecting the
name via_dri.so instead of unichrome_dri.so, and while I agree that the
latter is more representative for what it really is, it causes problems.
Perhaps a separate makefile is in place, or maybe a make
--- Thomas Hellstrom <[EMAIL PROTECTED]> wrote:
> Hi!
>
> It will be great to be able to build the 3d drivers in Mesa!!
>
> I was about to post a patch that enabled the building of the
> unichrome_dri.so as via_dri.so in the xc tree, but
> hopefully this will not be necessary.
>
> Here is were
Hi!
It will be great to be able to build the 3d drivers in Mesa!!
I was about to post a patch that enabled the building of the
unichrome_dri.so as via_dri.so in the xc tree, but
hopefully this will not be necessary.
Here is were the problem starts. All X side drivers are expecting the
name via
Ian Romanick wrote:
Ian Romanick wrote:
1. Enable GLX_SGI_make_current_read support in all drivers. The MGA
driver already supports this extension. I did a patch once, which
I'll have to find, that enabled it for r200, but the patch only worked
with pageflipping disabled. People can start wo
Ian Romanick wrote:
1. Enable GLX_SGI_make_current_read support in all drivers. The MGA
driver already supports this extension. I did a patch once, which I'll
have to find, that enabled it for r200, but the patch only worked with
pageflipping disabled. People can start working on this now, i
Ville Syrjälä wrote:
[...]
I want to bypass the drm to do accel from user space. Doing an ioctl() for
each blit feels very expensive. Rather than do an ioctl() for each blit
the drm could check the commands in the DMA buffer for bad stuff. But that
doesn't feel very efficient either.
If an ioct
On Mon, Feb 16, 2004 at 01:30:33PM +0100, Helge Hafting wrote:
> Ville Syrjälä wrote:
> [...]
> >
> >I want to bypass the drm to do accel from user space. Doing an ioctl() for
> >each blit feels very expensive. Rather than do an ioctl() for each blit
> >the drm could check the commands in the DMA
Ian Romanick wrote:
Roland Scheidegger wrote:
Ian Romanick wrote:
In-progress. Please test this branch! :) Would it be possible to
make the R200 nightly snapshot come from the branch instead (or in
addition to) the trunk? I'd like to merge to the trunk next Thursday
(19-Feb-2004). In order t
Roland Scheidegger wrote:
Ian Romanick wrote:
In-progress. Please test this branch! :) Would it be possible to
make the R200 nightly snapshot come from the branch instead (or in
addition to) the trunk? I'd like to merge to the trunk next Thursday
(19-Feb-2004). In order to feel comfortable do
Ian Romanick wrote:
Ian Romanick wrote:
1. Commit some minor changes to the r200 driver to use the new
interfaces. This will go in Mesa trunk, but will be guarded by
#ifdef. This is needed because the code calls some functions in
dri_util.c that only exist in the branch.
Done. Tomorrow I m
Ian Romanick <[EMAIL PROTECTED]> wrote:
> It looks like I should be able to convert the MGA driver today, but I
> can't make any guarantees.
I'd prefer the 'radeon' driver, because I gave my r200 card to my
friend ;-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its fri
On Thu, 12 Feb 2004 10:38:24 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Wed, 11 Feb 2004 18:56:39 -0800
> Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> [snip]
> > In-progress. Please test this branch! :) Would it be possible to make
> > the R200 nightly snapshot come from the branch ins
Martin Spott wrote:
Ian Romanick <[EMAIL PROTECTED]> wrote:
3. After some testing and "cool down" period, merge the branch into the
trunk. I expect this to happen fairly quickly.
In-progress. Please test this branch! :)
Would I notice any difference on a non-r200 card or do your changes
affect
Felix Kühling wrote:
On Thu, 12 Feb 2004 10:38:24 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
On Wed, 11 Feb 2004 18:56:39 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
[snip]
In-progress. Please test this branch! :) Would it be possible to make
the R200 nightly snapshot come from the branc
Ian Romanick <[EMAIL PROTECTED]> wrote:
>> 3. After some testing and "cool down" period, merge the branch into the
>> trunk. I expect this to happen fairly quickly.
> In-progress. Please test this branch! :)
Would I notice any difference on a non-r200 card or do your changes
affect r200 only
On Thu, 12 Feb 2004 10:38:24 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Wed, 11 Feb 2004 18:56:39 -0800
> Ian Romanick <[EMAIL PROTECTED]> wrote:
>
> [snip]
> > In-progress. Please test this branch! :) Would it be possible to make
> > the R200 nightly snapshot come from the branch ins
On Wed, 11 Feb 2004 18:56:39 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
[snip]
> In-progress. Please test this branch! :) Would it be possible to make
> the R200 nightly snapshot come from the branch instead (or in addition
> to) the trunk? I'd like to merge to the trunk next Thursday
> (
I've been getting a lot of mail about this both on and off list. First off, very
little code has been written, this is just a design concept.
One thing is clear there are two consoles involved. One is the system console
that receives printk's, the second is your garden variety command line termin
Ian Romanick wrote:
1. Commit some minor changes to the r200 driver to use the new
interfaces. This will go in Mesa trunk, but will be guarded by #ifdef.
This is needed because the code calls some functions in dri_util.c that
only exist in the branch.
Done. Tomorrow I may do some clean-up on
On Maw, 2004-02-10 at 00:30, Jon Smirl wrote:
> There are lots of solutions to this:
> 1) queue the printk's
Not a solution. The box crashed, game over, where is my data
> 2) add an in-kernel path for write to console that cooperates with the normal
> user space one
Ditto
> 3) if you know you a
Ian Romanick wrote:
Log message:
Incorporate all changes from the driinterface-0-0-2-branch.
Obtained from: driinterface-0-0-2-branch
In the past I have had a DRI / non-DRI time split of 90%/10%. As of
last Monday that switched to 10%/90%. This has caused me to change some
of the DRI re
On Tue, 2004-02-10 at 07:37, Ville SyrjÃlà wrote:
> On Sun, Feb 08, 2004 at 08:27:17PM -0800, Jon Smirl wrote:
>
> Here's a quick and dirty chart of how I think things should be organised.
>
> --
> user space
>---
>
--- Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> And finally I find the current situation with multi-head cards quite
> bad. I'd like the ablitity for a user space app to open the whole card
> as one entity. That includes all CRTCs, outputs and the whole memory
> (minus whatever is in use by other
On Sun, Feb 08, 2004 at 08:27:17PM -0800, Jon Smirl wrote:
> I have a new version of DRM at bk://mesa3d.bkbits.net/drm
> In it's current form it's 2.6 kernel only. Some support is generic but I've
> mainly be working on an R200. It is still under development with lots of work to
> do.
Ugh. I find
--- Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Mon, 9 Feb 2004, Jon Smirl wrote:
> >
> > There are lots of solutions to this:
> > 1) queue the printk's
> > 2) add an in-kernel path for write to console that cooperates with the
> normal
> > user space one
> > 3) if you know you are going to be
On Tue, Feb 10, 2004 at 08:41:40AM +1100, Benjamin Herrenschmidt wrote:
|
| - GL cannot be the _only_ API, simply because we don't (and may not have
| for some time) GL support on all cards, while still wanting this new console
| stuff so we don't have to keep the old cruft around
Just so long a
On Mon, 9 Feb 2004, Jon Smirl wrote:
>
> There are lots of solutions to this:
> 1) queue the printk's
> 2) add an in-kernel path for write to console that cooperates with the normal
> user space one
> 3) if you know you are going to be debugging code like this, use an alternative
> solution like
--- Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> Oh, and let me add that the notion of moving the console fully
> to userland is definitely not something that has been accepted.
>
> It is interesting to evaluate the solution, but lots of kernel
> folks will just turn it down for some simple
In my test system I run X from a PCI ATI Rage128, my target is a AGP Radeon
9000. So when I boot the Rage gets initialized and the Radeon does not. When you
load the Radeon DRM driver it will detect that the Radeon is not initialized in
the hotplug event. To make the reset automatic you need a link
On Tue, Feb 10, 2004 at 09:40:25AM +1100, Benjamin Herrenschmidt wrote:
> bk clone bk://mesa3d.bkbits.net/drm
> ERROR-Lock fail: possible permission problem.
Oops.
OK, fixed. Sorry for the inconvenience.
(In the future, please let [EMAIL PROTECTED] know of such problems.)
-andy
-
On Mon, 2004-02-09 at 22:41, Benjamin Herrenschmidt wrote:
[ lots of good points ]
I agree with your points Ben, thanks for bringing them up.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
On Mon, 2004-02-09 at 15:27, Jon Smirl wrote:
> I have a new version of DRM at bk://mesa3d.bkbits.net/drm
> In it's current form it's 2.6 kernel only. Some support is generic but I've
> mainly be working on an R200. It is still under development with lots of work to
> do.
bk clone bk://mesa3d.bkb
Oh, and let me add that the notion of moving the console fully
to userland is definitely not something that has been accepted.
It is interesting to evaluate the solution, but lots of kernel
folks will just turn it down for some simple reasons, like not
beeing able to printk bug reports from interr
> I haven't reached that stage yet so I'm open to any ideas that will work. Fell
> free to download the code and work on whatever interests you.
>
> My immediate goal is to get a login console up on a single screen. That means I
> need to get the mode set, make fonts work and write a mini-termina
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> --- Jon Smirl <[EMAIL PROTECTED]> wrote:
> > I have a new version of DRM at bk://mesa3d.bkbits.net/drm
> > In it's current form it's 2.6 kernel only. Some support is generic
> > but I've
>
> Nice work Jon! Very impressive! How about dualhead cards?
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> I have a new version of DRM at bk://mesa3d.bkbits.net/drm
> In it's current form it's 2.6 kernel only. Some support is generic
> but I've
> mainly be working on an R200. It is still under development with lots
> of work to
> do.
>
> Major features:
> 1)
I have a new version of DRM at bk://mesa3d.bkbits.net/drm
In it's current form it's 2.6 kernel only. Some support is generic but I've
mainly be working on an R200. It is still under development with lots of work to
do.
Major features:
1) Get VBIOS ROM contents IOCTL
2) Driver automaps the registe
On Thu, 2004-01-29 at 07:15, Felix Kühling wrote:
> Thanks. I see you used my versions of the scripts as a basis. BTW, these
> scripts are also in CVS, though your latest changes are obviously not
> committed yet. Are you going to keep maintaining the scripts in CVS?
nope, I'm leaving for 3 months
On Thu, 29 Jan 2004 10:52:25 -0800
Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Thu, 2004-01-29 at 07:15, Felix Kühling wrote:
> > Thanks. I see you used my versions of the scripts as a basis. BTW, these
> > scripts are also in CVS, though your latest changes are obviously not
> > committed yet. Ar
Thanks. I see you used my versions of the scripts as a basis. BTW, these
scripts are also in CVS, though your latest changes are obviously not
committed yet. Are you going to keep maintaining the scripts in CVS?
Regards,
Felix
On Wed, 28 Jan 2004 14:35:19 -0800
Eric Anholt <[EMAIL PROTECTED]> w
One more thing I noticed: extras/xdriinfo.bz2 is no longer needed. It's
included in the snapshots. So in order to avoid unnecessary confusion it
could be removed from the download area.
Regards,
Felix
---
The SF.Net email is sponsored by Ecli
http://dri.sourceforge.net/cgi-bin/moin.cgi/Download has new
instructions for getting the new nightly snapshots that are built from
freedesktop.org, now that we got cron working properly. The scripts are
in /home/projects/dri/snapshots, and should be writable by other project
members. The cronjob
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Br
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Br
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Br
Daniel Vogel wrote:
Yes certainly. But software decompression of textures really should
never happen in games (performance of software rasterization really
FWIW, that's how we handle support for cards that don't support texture
compression as we store our textures pre- compressed. I agree though
> Yes certainly. But software decompression of textures really should
> never happen in games (performance of software rasterization really
FWIW, that's how we handle support for cards that don't support texture
compression as we store our textures pre- compressed. I agree though that it
doesn't
Daniel Vogel wrote:
[replying to multiple people]
They also enable the old, undocumented, dead and buried GL_S3_s3tc
extension
http://oss.sgi.com/projects/ogl-sample/registry/S3/s3tc.txt
Yes, but everything there just says "unknown" - no compression format,
nothing interesting at all (except t
[replying to multiple people]
> They also enable the old, undocumented, dead and buried
> GL_S3_s3tc extension
http://oss.sgi.com/projects/ogl-sample/registry/S3/s3tc.txt
> Note that the alpha decompression of DXT5 (in txformat_tmp.h) is
> horribly broken - stupid bug, the version from the ear
Dieter Nützel wrote:
(needed for QuakeIII/rtcw, don't know about
rtcw:et). This time I haven't tested the r200 patch, only radeon so use
at your own risk.
Using 8/8/8 Color bits, 24 depth, 8 stencil display.
GL_RENDERER: Mesa DRI R200 20030328 AGP 4x x86/MMX+/3DNow!+/SSE TCL
Initializing OpenGL e
Am Mittwoch, 14. Januar 2004 06:29 schrieb Dieter Nützel:
> Am Sonntag, 28. Dezember 2003 23:00 schrieb Roland Scheidegger:
> > ok, here it is, the long-awaited, highly controversial new patch ;-).
> > (patches against current Mesa cvs, if you used the older version you
> > need to reverse it first
Am Sonntag, 28. Dezember 2003 23:00 schrieb Roland Scheidegger:
> ok, here it is, the long-awaited, highly controversial new patch ;-).
> (patches against current Mesa cvs, if you used the older version you
> need to reverse it first).
> The radeon/r200 patches have a texture alignment problem (wit
Well well, i just tried the patched version of the CVS tree with ut2003
and it's simply great, textures are just looking fine and the game is
far more playable than it used to be, yet i had to disable TCL to avoid
having purple textures sometimes. It really would be a shame if this
patch wasn't int
Hi,
Patch is working very nicely on my 9200, textures look great in NWN.
q3a runs fine as well although I didn't play around with the texture
settings much.
Many thanks.
Regards
Steve.
---
This SF.net email is sponsored by: IBM Linux Tu
Unless anyone says otherwise, I'm going to remove this code. All it
has done is generate complaints from MergedFB users. Apparently it
doesn't hurt anything (ie. cause a crash) to leave direct rendering
enabled if the virtual desktop is larger than 2048. Since MergedFB
users seem to be the only
On Sat, 2003-10-18 at 12:27, Keith Whitwell wrote:
> Eric Anholt wrote:
> > On Fri, 2003-10-17 at 17:27, Alex Deucher wrote:
> >
> >>perhaps we can not disable the DRI if mergedfb is active and the viral
> >>is larger than 2048?
It was only MergedFB which made this necessary...
> > Maybe in the
On Fri, Oct 17, 2003 at 05:27:36PM -0700, Alex Deucher wrote:
>
>I've had several mergedfb users complain about the 2048 DRI limit
> put in yesterday:
>
> else if ( pScrn->virtualX > 2048 || pScrn->virtualY > 2048 ) {
> info->directRenderingEnabled = FALSE;
>
On Fri, 2003-10-17 at 17:27, Alex Deucher wrote:
>I've had several mergedfb users complain about the 2048 DRI limit
> put in yesterday:
>
> else if ( pScrn->virtualX > 2048 || pScrn->virtualY > 2048 ) {
> info->directRenderingEnabled = FALSE;
> xf86DrvMsg(sc
I've had several mergedfb users complain about the 2048 DRI limit
put in yesterday:
else if ( pScrn->virtualX > 2048 || pScrn->virtualY > 2048 ) {
info->directRenderingEnabled = FALSE;
xf86DrvMsg(scrnIndex, X_WARNING,
"Dire
On Fri, 2003-09-12 at 00:01, Mike Mestnik wrote:
>
> The main goal is to get a working DRI that has the new API, and maby some gatos
> bells and
> whistles. I'm assuming you read my post that recent DRI is to different from gatos.
> My plan was
> to diff gatos and DRI and weed ought all the c
Hello Laurent,
The main goal is to get a working DRI that has the new API, and maby some gatos bells
and
whistles. I'm assuming you read my post that recent DRI is to different from gatos.
My plan was
to diff gatos and DRI and weed ought all the changes that where depreciated. With
that patc
I just wanted to let every body know where this sat. Unfortunately I will not have
time to work
on it much this moth, I have to get my bills straightened ought. I did look into it
and found
that gatos and latest DRI are vary different I would recommend finding an
older(2003/02/25 is the
Xfree8
On Thu, 2003-09-04 at 02:18, Mike Mestnik wrote:
> --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > On Sat, 2003-08-30 at 18:27, Mike Mestnik wrote:
> > > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > > On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
> > > > > I have something to add to this.
Mike Mestnik wrote:
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
On Sat, 2003-08-30 at 18:27, Mike Mestnik wrote:
--- Michel Dnzer <[EMAIL PROTECTED]> wrote:
On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
I have something to add to this. Recently I tested gatos drivers going
from dri to gat
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sat, 2003-08-30 at 18:27, Mike Mestnik wrote:
> > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
> > > > I have something to add to this. Recently I tested gatos drivers going
> > > > from dri t
For those that are interested, I just wanted to mention that I've
posted new versions of my radeon mergedfb patch and my radeon
powermanagement patch. Please see bugzilla for more details. Binaries
and diffs are available on my website (listed on bugzilla).
Mergedfb:
http://bugs.xfree86.org/show
Felix Kühling wrote:
This is just a matter of how clever you make the graphical configuration
tool. The way I just implemented it in driconf (not yet released)
doesn't consider partial internationalisation. IMHO, if someone
translates the description of an option he/she should translate all enum
d
On Mon, 28 Jul 2003 11:05:57 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
>
> > I believe this solution is very flexible and keeps the implementation
> > complexity small as the drivers don't need to parse symbolic values from
> > configuration files. Comments?
>
> Yes.
Felix Kühling wrote:
I believe this solution is very flexible and keeps the implementation
complexity small as the drivers don't need to parse symbolic values from
configuration files. Comments?
Yes. This looks very good. The only possible issue is in specifying
how "partial" internationalizati
Hi,
I promised more details about a new option type "enum" in the
configuration scheme. Basically it is jut a special case of an integer
that _requires_ a "valid" attribute in the driver's XML document in
order to guarantee enumerability. Furthermore individual values _can_
(but don't need to) be
get larger balls and penís,
more
pleasure,
more
satisfactíon
Fínd out more here
No more please
-=ccfuri13g6cz6=-
+wzf¢+,¦ì¢·o'k!¶ßǪè©éí~åzË(àZÊm§ÿÚuö«gªe{(öýÉ?ï]uׯ{ëÝzä:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿ
1 - 100 of 194 matches
Mail list logo
