> Where DRI is not supported it's not used, why should any other driver be
> forced to work every where?
All the current drivers barring some OS specific things like Linux frame
buffer driver work when DRI isnt available on that platform and fall
gracefully back to 2D with software 3D, including t
On Iau, 2004-06-10 at 20:50, Alan Hourihane wrote:
> O.k. I've popped the 2D ddx into XFree86's CVS, followed up by a merge
> of a snapshot of Mesa 6.1 from back in March time. Along with that, I've
> also merged in the latest DRM kernel modules in XFree86's tree as well.
Is the 915 driver code li
On Iau, 2004-06-10 at 10:46, Dave Airlie wrote:
> okay I've checked this into the drm bk tree and DRM CVS, I've no way to
> test it apart from visual inspection and it compiles, I've asked Linus to
> sync the drm tree again, I probably need to add some __user annotations in
> a few places..
I've g
On Sul, 2004-06-13 at 16:34, Jon Smirl wrote:
> The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't
> get to work on a response. Getting mesa-solo running everywhere wouldn't take
> two years if more people would pitch in and quit arguing. Right now we should
> have a wor
On Sul, 2004-06-13 at 22:41, Jon Smirl wrote:
> On modern processors the user/system transition is minor compared to the time
> needed for a bitblt over the PCI bus.
As a percentage of system time the user/system transition cost has been
rising not falling on x86 processors. Its especially bad wh
On Sul, 2004-06-13 at 20:47, Matt Sealey wrote:
> Linux basically falls behind on two simple fronts at the moment:
> it has no "simple" 2D or 3D framework capable of much more than
I deal with embedded Linux people on a daily basis. I think they would
disagree. For 2D it has several in heavy use
On Sul, 2004-06-13 at 03:07, Jon Smirl wrote:
> Why not help getting mesa-solo working so that we can move to X on top of
> OpenGL?
For one, in the two years that is going to take to bear fruit, we need a
working X server. Two because mesa-solo isnt supported on most of
the Xorg platforms.
Alan
On Sul, 2004-06-13 at 20:35, Jon Smirl wrote:
> The work that would be wasted is extending the XAA 2D drivers to use the 3D
> hardware to accelerate render.
Lots of hardware can do render without 3D operations. Even my
TV capture/playback card has blit-with-alpha on it. Extending existing
XAA dri
On Sul, 2004-06-13 at 20:20, Torgeir Veimo wrote:
> At least he is trying. There's no need for bashing people who try to
> implement new ideas.
I'm not. I'd rather he listened to new ideas and took feedback but that
is his business and the community has ways of dealing with that problem
that work
On Sul, 2004-06-13 at 22:58, Mike Mestnik wrote:
> The DRM is a kernel driver that allowes the user-apps to use a 3D cards
> API. Fbdev is smaller then the DRM and will be asimulated and it's
> functions emulated or replaced.
On Linux and FreeBSD only, and there isnt yet a consensus on the
Fbdev
On Sad, 2004-06-12 at 00:53, Ian Romanick wrote:
> I think I would actually prefer it if the 3D were named unichrome_dri.so
> and the DDX were changed. The reason being that there will likely be
> future "via" chipsets that may share the 2D driver but not the 3D. The
> current situation of ati
On Gwe, 2004-06-04 at 01:10, Dave Airlie wrote:
> Do you know if the VIA DRM is considered secure with respect to DMA
> buffers and the like? I've been thinking of pushing it to Linus,
It certainly needs further review. As I understand it the VIA one should
be ok, but the S3 one that went over the
On Sul, 2004-06-06 at 05:34, Alex Deucher wrote:
> > at http://www.cirrus.com/ftp/pub/gd5465trm.pdf. Since it used to be
> > publicly available, perhaps you could just ask the nice folks at
> > Cirrus
> > Logic for it?
>
> You might also still be able to get it on the internet archive.
Cirrus
trees. your best bet may be to just grab unichrome's tree or
> grab the source Alan Cox fixed up. On the other hand, I'm not really
> an expert on VIA development, so I may be wrong.
The DDX in Xorg should work fine with the DRI modules assuming they
applied the patches. If not then
On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
> There are two types of VTs - text and graphical. It is only practical to have a
> single graphical VT because of the complexity of state swapping a graphical VT
> at VT swap.
Could have fooled me. I can switch between multiple DRI using X servers
and
On Iau, 2004-05-20 at 01:55, Jon Smirl wrote:
> It's not going to allow multiple login prompts on different VTs on the same
> head.
In which case its completely useless. You might want to get away from a
kernel virtualisation of video services but you just can't do it. You
can pull a *lot* of the
On Mer, 2004-05-19 at 20:49, Jon Smirl wrote:
> A rep from the SELinux group was at the Xdev conference. They are starting a
> project to verify X server.
Verifying the X server isnt practical. Its large and its reliant on
hardware behaviour for hardware where nobody has documentation and where
th
On Mer, 2004-05-19 at 20:30, Jon Smirl wrote:
> xserver draws each app into it's own pbuffer. The individual apps don't have
> access to the main framebuffer. A properly designed xserver should be free from
> the screen scraping attack too. The DRM module will have to make sure you can't
> read buf
On Maw, 2004-05-18 at 23:27, Keith Packard wrote:
> No thoughts to supporting multiple sets of VTs, one per physical device
> then?
That would be nice but how much of that needs to be kernel side. Not a
lot I suspect.
---
This SF.Net email is
On Mer, 2004-05-19 at 01:35, Jon Smirl wrote:
> Why does VT switch have to be in the kernel? I can have multiple xterms logged
> in as different users without kernel support. Why can't VT switching be
> implemented as if I was switching between multiple fullscreen xterms? I guess I
> don't see why
On Maw, 2004-05-18 at 21:14, Jon Smirl wrote:
> I was thinking ptmx/pty, or do you want to use tty? With ptmx/pty you can get
> rid of the tty devices.
You need the tty devices for the boot/kernel console and the code
specifc to them is tiny. For the usermode one its clearly ptmx/pty
> I wasn't t
On Maw, 2004-05-18 at 01:07, Vladimir Dergachev wrote:
> Alan, perhaps I am missing something, but 4Mb seems a little low.
> 1280x1024 at 32bpp takes up 5Mb.
>
> Or is it a really old card ?
Its an old card but happens to have public docs so its one I can
talk about without having to work out if
On Maw, 2004-05-18 at 01:13, Jon Smirl wrote:
> 1) Boot console. This is implement via BIOS support. It is used to printk a
> processor initialization failure or failure to find initramfs. Some embedded
> systems might have to build one of these into the kernel but not a normal
> desktop machine. T
On Llu, 2004-05-17 at 04:10, David Bronaugh wrote:
> Why not just be able to query how much physical video RAM is -not-
> allocated?
>
> It sounds to me like this would solve the problem.
Lots of hardware has quite complex policy rules for the layout of
specific objects. Nor is unallocated ram s
On Gwe, 2004-05-14 at 19:40, Jon Smirl wrote:
> Does DirectFB work on anything beside Matrox now?
Most cards, accelerated on quite a few including VIA. This is getting
into detail. If your 3D sucks you dont us OpenGL as the basis of your
whizzo console driver - just as MS plan to support the older
On Iau, 2004-05-13 at 01:58, Jon Smirl wrote:
> --- Alan Cox <[EMAIL PROTECTED]> wrote:
> > argument for _good_ console support becomes that after boot you run a
> > graphical user space console app built with OpenGL, antialiased true
>
> When I proposed this a couple
On Llu, 2004-05-17 at 18:49, Keith Packard wrote:
> Composite doesn't really expose things in a way that would make this
> hardware capability usable.
>
> Instead, it expects the video to be painted into the window pixmap so that
> those pixels can be composed to form the screen image.
For Xv t
On Mer, 2004-05-12 at 20:04, Sottek, Matthew J wrote:
> >On that basis the kernel driver really can be argued to be boot/debug
> >only.
>
> I don't see this leap?
Unclear on my part sorry - I was just referring to the text-mode
console bits not the entire system
On Maw, 2004-05-11 at 19:48, Egbert Eich wrote:
> For the text console to be usable you possibly want to be able to
> 1. move the fb start address for scrolling
> 2. to do some basik 2D accel for fast text drawing
I thought about this a bit more. Let me propose a different viewpoint as
a result.
On Maw, 2004-05-11 at 19:48, Egbert Eich wrote:
> For the text console to be usable you possibly want to be able to
> 1. move the fb start address for scrolling
> 2. to do some basik 2D accel for fast text drawing
>
> Also your framebuffer may not be completely linear.
In which case bank switc
On Maw, 2004-05-11 at 20:55, James Simmons wrote:
> Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't
> never win this fight. There is MONEY involved here. This is a sure way
> to make sure Tungstengraphics has a income coming in. They want a monoply
> on the linux graphics
On Llu, 2004-05-10 at 17:14, James Simmons wrote:
> Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be
> moved to userspace. The networking code alone is over 17 megs in size.
Not on my box. Nothing like it. Although to answer that question with a
definitive example ELKS (
On Llu, 2004-05-10 at 12:46, Egbert Eich wrote:
> Yes, we will most likely need OS dependent non-chipset specific wrappers,
> but those are cheap to do - a lot cheaper than code dealing directly
> with chipset quirks.
Well the minimal kernel side stuff required to make hot plug work
is going to be
On Sul, 2004-05-09 at 17:45, Jon Smirl wrote:
> Also, these is no rule saying a device driver can't have several tables of _init
> register values that can be used to set the mode on a primary monitor at boot. I
> would just like to see all of the code that does DDC decoding and modeline
> computat
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
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
On Gwe, 2004-05-07 at 21:59, Egbert Eich wrote:
> However chipset probing/display device probing and mode setting isn't
> required to live in kernel space. Portability and system stability
> arguments speak against it. In fact only Apple MAC users seem to
> advocate this idea to be able to an init
On Iau, 2004-05-06 at 09:39, Egbert Eich wrote:
> Furthermore I'd argue that as little as necessary should live in the
> kernel space. One thing that - in my opinion - should *not* live in
> there is mode detection and initialization.
There is a need to handle some mode setup/init in the kernel (
Standard problem with Wiki nowdays. Lots of dubious companies have
crawlers that spam wikis with their URL then ask google to index
the page to boost their google rating 8(
---
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
On Llu, 2004-04-26 at 03:38, Vladimir Dergachev wrote:
> So the next question would be how does one hack radeon or r200 driver to
> get down to a particular function ?
When I was trying to debug the sis6326 and via drivers the best way I
found with those was to turn on fallbacks for everything tha
On Gwe, 2004-04-23 at 18:52, Ian Romanick wrote:
> I'm not too familiar with __user. What is it's purpose? Is it only
> meaningful when building in the kernel?
It identifies a pointer as being to user not kernel data. That means
you can then do checks that it is only accessed through the right
On Mer, 2004-04-21 at 02:03, Jon Smirl wrote:
> coming of MS Longhorn is going to cause of shift in typical PC configurations to
> ship with 3D hardware standard. Microsoft is going to cause this shift no matter
> what happens with Linux. It's just up to us to decide if we want to take
> advantage
On Maw, 2004-04-20 at 18:26, Jon Smirl wrote:
> The kernel provides symbols for all of the PCI ID constants via pci_ids.h. The
> strings describing the hardware are duplicated against drivers/pci/pci.ids. How
pci.ids isnt used by 2.6, its primarily used by lspci in user space, and
the name stuff h
On Maw, 2004-04-20 at 18:35, Jon Smirl wrote:
> This is a post from the Cairo list. It benchmarks a Cairo program against image,
> xrender, glx implementations of Cario. You can see that 2D drawing is a the
> minimum 10x faster and sometimes 200x or more when using the 3D hardware. Data
For one be
On Llu, 2004-04-19 at 21:21, Jon Smirl wrote:
> Do you really want to teach FB about setting modes on multiple heads?
Yes and I know it needs to know about memory management too. Lots of
cards need memory management anyway either for textures or even AGP
drawn frame buffers.
A lot of the computat
On Llu, 2004-04-19 at 17:00, Jon Smirl wrote:
> These PCI changes duplicate things that are in framebuffer. Shouldn't we be
> having a giant argument about them? I would think that is worse that DRM is is
> duplicating something in FB. The two IOCTLs I needed for reset don't exist in
> either FB or
On Sul, 2004-04-18 at 07:52, Ryan Underwood wrote:
> So your advisor is saying that such a work is undistributable under the
> GPL, or are they saying that it is not distributable at all?
They are saying that in their reading of the law it would be better
if the firmware was kept seperate. Lawyers
On Sad, 2004-04-17 at 19:40, Ryan Underwood wrote:
> Of course, if the legal advice you refer to was specifically aimed at
> the firmware scenario, where you have a blob of who-knows-what that does
> not execute on the host embedded into a driver binary, then I'm not one
> to argue with that.
It w
On Sad, 2004-04-17 at 06:44, Ryan Underwood wrote:
> 3) Neither of these is ok, must go into non-free because binary-only
> firmware doesnt meet DFSG (no source) regardless of its license. Either
> whole driver must go into non-free, or a crippled driver is provided in
> main and a userspace loade
On Iau, 2004-03-18 at 00:00, Jon Smirl wrote:
> For cards where we don't have the protected mode code I have provided a vm86
> solution. This solution works by jumping to C000:3 in the BIOS image. Right now
> this scheme does not work on non-X86 machines (you need emu86). It also does not
> work on
On Mer, 2004-03-17 at 19:40, Jon Smirl wrote:
> secondary cards if needed. The patch works by generating a hotplug event on
> driver insertion. This event calls a user space helper - video-reset. Video
> cards can be reset from user space using VM86 mode.
Sometimes. Many of these drivers require s
On Llu, 2004-03-15 at 17:53, Jon Smirl wrote:
> adapters installed. A much better fix for this would be to alter the Linux
> kernel to initialize these adapters during the very beginning of the boot
> process before entering protected mode. This is really a BIOS shortcoming that
> we are trying to
On Maw, 2004-03-16 at 22:32, Thomas Hellstrom wrote:
> and a dri / OpenGL implementation which Alan Cox fixed up some time ago
> and which is downloadable from your site. I don't think it has been
> ported to be compatible with dri CVS though.
Just for 4.3.x, not CVS that is cor
On Sul, 2004-03-14 at 20:00, Jon Smirl wrote:
> However, I am saying that we need a blend between framebuffer and DRM. Not DRM
> bolted on top of framebuffer.
You keep imposing policy in the mid layer. How do you know whether you
need a blend or not - its card specific. Some cards have 2D/3D sepe
On Llu, 2004-03-15 at 16:51, Ian Romanick wrote:
> Jon Smirl wrote:
>
> > 1) GET_VBIOS -- gets a copy of the board's video BIOS ROM. It is implemented
> > 2) VGA_ENABLE -- this is used to control the active VGA card in the system.
> > 3) BLANK - simple call to allow Vesa power management to blank
On Sul, 2004-03-14 at 02:50, Jon Smirl wrote:
> 1) Use SysReq to get to kernel console. In this model the kernel console is
> always active, it's just hidden. Hit SysReq and it appears. Hit an oops or panic
> and it will appear too. The video driver has enough state information to make
> this conso
On Sul, 2004-03-14 at 16:29, Jon Smirl wrote:
> You're right that DRM is not tied to the OpenGL API. But what about things like
> memory management of the video RAM and AGP space? Right now that is happening
> inside of the OpenGL libraries.
Much of it has to. The allocation rules vary by card. DR
On Sad, 2004-03-13 at 16:35, Jon Smirl wrote:
> Yes. Big chunks of Benh's driver and the mode parts of fb can easily be moved to
> user space. It only took a couple of days. Mode setting code is seldom used as
> compared to an interrupt handler, this gives the space back for more important
> things
On Gwe, 2004-03-12 at 21:40, Ian Romanick wrote:
> MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit
> because I don't intend to (initially) support PCIGART. Even when
> PCIGART is supported, not all chips in the MGA family support it. Is
> the PCI G450 the only one?
Is there
On Llu, 2004-03-01 at 16:28, Michel DÃnzer wrote:
> For my part, I'd certainly prefer staying clear of the silly new
> license. In the long run, I'd vote for moving the DRI X server code to a
> freedesktop.org X server tree and the libGL code to Mesa or its own
> xlibs module.
I'd definitely like
On Llu, 2004-03-01 at 14:34, Adam K Kirchhoff wrote:
> The client libraries are still distributed under the old license, so there
> is no problem linking GPLed libraries or apps to the 4.4 libraries. Which
> means there is no longer a reason for those distributions not to include
> 4.4 any more.
On Llu, 2004-02-23 at 19:33, Dieter NÃtzel wrote:
> What about this (Not only for "AMD"):
>
> AMD recommends to perform memory copies with backward read operations
> instead of prefetch.
If you try that in the real world with cached data it gives really bad
results compared to prefetch - so its
On Llu, 2004-02-23 at 16:35, Ian Romanick wrote:
> Alternately, this might be a case where writing a little assembly
> conversion routine would help. If we assume at least a 486 instruction
> set (eh-hem!), the core of the BGR to ARGB conversion should take about
> 6 or 7 instructions, includin
On Sul, 2004-02-22 at 21:26, Chris Ison wrote:
> these functions out into all the different types so each conversion type is
> done as fast as possible. Looking at it atm, (using my unrelated exprience
> in audio sample format convertion) these could be dramatically spead up by
> doing doing up fun
On Gwe, 2004-02-20 at 18:06, Keith Whitwell wrote:
> The patch looks ok to me, though I really don't know the code in this area
> particularly well. Any comments from anyone before applying?
VIA branch is out of date (I've been way too busy lately) but yes Im
happy, and the fix is relevant to th
On Iau, 2004-02-19 at 02:02, Alex Deucher wrote:
> 2D: do to a bug in S3's code, 2D accel was never enabled when the DRI
> was active. I've managed to get 2D accel working again. one question
> I have, I assume xf86InitFBManager() should only manage memory for 2D
> stuff? Otherwise it would conf
On Iau, 2004-02-19 at 03:10, Erdi Chen wrote:
> Is this a known problem? Has it been fixed? I have to add a linked list
> to VIA's DRM to keep track of context handles and perform clean up when
> release is called on the DRI file descriptor. I will gladly create a
> patch if this is a real probl
On Llu, 2004-02-16 at 16:42, Thomas Biege wrote:
> I attached my enhanced (hot-) fix patches. The same bugs appear in the
> drm4/ subdirectory too.
>
> Alan, were is the upper limit of 4096 for 'count' from?
Random safe number that seemed sufficient.
-
On Gwe, 2004-02-13 at 11:31, Thomas Biege wrote:
> Hi,
> one of our developers mentioned that depth->n can be negative.
>
> I didn't checked the whole code but even if depth->n is unsigned,
> count is signed and can be negative by using a depth->n > INT_MAX.
>
> Is this a real problem or do we ju
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
On Mer, 2004-01-21 at 00:28, Adrian Bunk wrote:
> > Fix system.h to always define cmpxchg.h and check its presence at
> > runtime when the DRM module loads, then you can build 386 kernels that
> > support DRI on higher machines.
> >
> > The problem isnt that cmpxchg definitely doesn't exist, so sy
On Maw, 2004-01-20 at 21:24, Adrian Bunk wrote:
> I got the following compile error in 2.6.1-mm5 with X86_CMPXCHG=n.
> This problem is not specific to -mm, and it always occurs when you
> include support for the 386 cpu (oposed to the 486 or later cpus) since
> in this case X86_CMPXCHG=n and ther
On Sul, 2004-01-18 at 01:56, Alex Deucher wrote:
> I'm not sure if this is a leak per se... the problem is the 2D and 3D
> driver aren't too good at managing memory. the 3D driver may snag a
> big chunk for a full screen 3D app and then "keep" it. It's then no
> longer available for the 2D driver
On Iau, 2004-01-15 at 20:47, Alex Deucher wrote:
> Makes sense. I know what might help clear this up. Alan, do you still
> have a copy of the VIA/S3 source with pbuffer support? I'm curious as
> to how they did it.
On the VIA pbuffer is unaccelerated, the 2D memory view is also linear
although th
ETY CRITICAL SYSTEMS
+ *
* Authors:
*Gareth Hughes <[EMAIL PROTECTED]>
+ *
+ * Memory allocation size checks added 14/01/2003, Alan Cox <[EMAIL PROTECTED]>
*/
#include "r128.h"
@@ -901,6 +913,9 @@
DRM_DEBUG( "%s\n", __FUNCTION__ );
On Sul, 2004-01-11 at 20:43, Jesse Merriman wrote:
> Alex Deucher wrote:
> > hmmm... if both agpgart and savage are loaded before X starts, I'm not
> > sure what your problem would be. what does your kernel log or dmesg
> > say when you load the modules?
>
> Here's the end of my dmesg:
>
> Linux
Can whoever is currently maintaining the r128 driver in
Linux and *BSD drop me a mail.
Alan
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching ca
Ok I am now happy with the testing on the VIA CLE266 driver. Would
someone care to pick up the dri module for it from
http://people.redhat.com/~alan/
The 2D support is already in XFree 4.3.99 CVS. The 3D code is a port of
the VIA provided 3D code with their extensions to core mesa removed
(they
On Gwe, 2004-01-09 at 00:39, Eric Anholt wrote:
> Uhoh, the SiS is my fault. I'll take a look soon.
Thats ok - I found it because I screwed up textures on your sis6326 code
8)
---
This SF.net email is sponsored by: Perforce Software.
Perforc
On Iau, 2004-01-08 at 20:08, Robert T. Johnson wrote:
> Both of these bugs look exploitable. The vt.c patch is
> self-explanatory.
>
> In gamma_dma.c, argument "d" to gamma_dma_priority() points to a
> structure copied from userspace (see gamma_dma()). That means that
> d->send_indices is a po
On Iau, 2004-01-08 at 15:36, Adrian Bunk wrote:
> On Wed, Jan 07, 2004 at 11:28:31PM -0800, Andrew Morton wrote:
> >...
> > - Added the latest code drop from DRM CVS. People who use DRM, please test
> > it.
> >...
>
> I got the following compile error:
I got it to crash the kernel. Build with
On Iau, 2004-01-08 at 19:20, Linus Torvalds wrote:
> It really looks like all the math should be quite doable with just regular
> integer code. You'd need to use 64-bit integer division (some of the
> values involved are large), but it doesn't look fundamentally hard.
>
> Somebody that knows the
I had to do something to restore my normal insanity levels so I've
been poking at Eric Anholt's SIS6326 driver. I've fixed various things
and ported it to run with XFree 4.3.0 (plus some small 2D backports) and
the 4.4CVS dri module for sis.
At the moment the basic 3D stuff works. The locking with
On Gwe, 2004-01-02 at 16:11, Michel DÃnzer wrote:
> On Fri, 2004-01-02 at 03:20, Alex Deucher wrote:
> MergedFB seems to be the clearly better overall approach than
> traditional Xinerama to me...
Its simple but its a lot less flexible. I'm not entirely sure the VIA
approach is the entire needed
On Gwe, 2004-01-02 at 02:20, Alex Deucher wrote:
> Does the via driver support 3D with dualhead? It seems to. I noticed
> the following code in via_context.c:
In theory it does. I don't know if the 4.3 based one does because VIA
also changed the core Mesa stuff to add things like pbuffer support
- 3D now works with 2D acceleration enabled
- Chromium BSU runs entirely
- Window overlapping now works
- Tuxracer works except that the initial screen has a pale brown
not a pale blue background (any ideas anyone ?)
- Most screensavers run - morph3d and pipes crash
- Several screensavers (but n
On Iau, 2004-01-01 at 13:50, Michel DÃnzer wrote:
> > Okay, you did something weird with nopage args, but I thought I did
> > the equivalent of this in the original patch?
>
> This is about the canonical DRM code in the DRI tree.
99.9% of people run the DRM code in the kernel tree, so definitions
I "played" tuxracer using XFree 4.3.0 and my test code last might. Depth
buffering in some cases is shot, there is a lot of fallback stuff
occuring for clipped polygons that isnt working and things are a
peculiar brown colour (someone suggested thats fog issues).
Textures sometimes go missing, it
On Llu, 2003-12-29 at 19:52, Linus Torvalds wrote:
> Especially a patch that only passes the compressed textures down to the
> hardware - it might make sense to not even have a software fallback.
> After all, the only people who care about this patch are game users, and
> those people likely do n
On Llu, 2003-12-29 at 09:45, Alan Hourihane wrote:
> Doing it this way, we'd need to have regular releases of the DRM kernel
> modules and tag them with CVS keywords. But I'm all for this too.
This makes sense for development. Also in Linus proposed model the
kernel framebuffer drivers are themsel
On Sul, 2003-12-28 at 17:16, Roland Scheidegger wrote:
> btw I don't think you can lose a patent, even in europe. You can lose
> trademarks if you don't defend them. If a patent is actually valid and
> can be enforced (bascially court will decide this, not patent office) is
> a different matter
On Sul, 2003-12-28 at 16:55, Dieter NÃtzel wrote:
> We have asked (S3/VIA etc.) so many times for advice, but haven't had any
> definitive answer, even sometimes NO answer at all.
I don't think S3, VIA and friends even know who actually owns it right
now.
You need to distinguish between:
On Maw, 2003-11-25 at 20:26, Michel DÃnzer wrote:
> * Our drivers do something which makes newer chips perform very
> poorly with PCI GART, be they AGP or PCI
>
> The former wouldn't necessarily say anything about PCI cards, but I'm
> not sure how to determine which it is (and what e
On Sul, 2003-11-16 at 12:05, Ville SyrjÃlà wrote:
> And apparently it's nobody's job to fix the bugs...
>
> > Furthermore, developer relations ignores any questions about
> > the Parhelia period. :(
>
> Developer relations ignore all questions/requests :( They even removed the
> developer relati
On Mer, 2003-10-15 at 21:07, Alex Deucher wrote:
> the 3D drvier needs to be updated to mesa 5.x. Not much work has been
> done on it and I think there are some issues with the 2D driver.
> There's no way it will make it into 4.4.0. the current code is on a
> branch in DRI cvs. If you are inter
On Gwe, 2003-10-10 at 23:16, Ian Romanick wrote:
> on some it's dumped but the driver has a change to back it up, and on
> others it's just dumped.
>
> AFAIK, perhaps someone can correct me, XFree86 on Linux falls into the
> last category.
It depends on the BIOS and other factors. For ACPI it i
On Iau, 2003-10-09 at 17:16, Alan Hourihane wrote:
> I've just committed a version of the DRI's common code mm.[ch] linear allocator
> into the XFree86 CVS which extends the FBManager's ability to serve
> real linear space rather than pinching it from the XY area's that's
> usually occupied by the
On Iau, 2003-10-02 at 12:46, Sven Luther wrote:
> radeon R200 core (8500, 9000, 9100 and 9200). Newer radeon cards and
> nvidia stuff are only supported with the proprietary drivers, and there
> is proprietary servers for another bunch of high-end cards.
If you go with the binary cards with kernel
201 - 300 of 455 matches
Mail list logo
