Ian Romanick wrote:
Nothing about DRI prevents a developer from choosing a different kernel
/ user split. Based on the size of their kernel modules, I'm pretty
sure that both 3dlabs and ATI made a different choice. However, they
support Linux only and they aren't distributed with the kernel so
Tomas Carnecky wrote:
Ian Romanick wrote:
Tomas Carnecky wrote:
The dri/drm interface seems to be quite low-level. I heard somewhere
that different devices have quite different registers and work in a
quite different way. If it is true that it would be better to make a
more high-level interface whe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 25 May 2004 23:43, Maurice van der Pot wrote:
> The modifications I made to the driver were visible when I executed an
> OpenGL app, so I knew it was using the right r200_dri.so. Strangely,
> I was unable to get most of the debug prints wor
Tomas Carnecky wrote:
David Bronaugh wrote:
Another option would be to design a generic, more low-level wrapper
for graphics hardware. In my opinion this is a huge undertaking (ever
read chip docs? You try integrating 3000 pages of information (that
would be around 5 different chips)). However,
--- Tomas Carnecky <[EMAIL PROTECTED]> wrote:
> My idea is that every card creates a device node in /dev which can be
> openend by anyone with appropriate rights. With each device is a
> userspace library associated which has implemented the interface
> functions (gl*). The interface between user
I think every thing Tomas Carnecky has said here about device driver
design is valid and dose apply to the DRM/dri. He may not know every
thing about system security, but we also all have our strangths and his
strangth is oviously device design. One way of interpeting what he is
trying to say is
Am Montag, 24. Mai 2004 23:53 schrieb Michel DÃnzer:
> On Sun, 2004-05-23 at 22:52, Dieter NÃtzel wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x40670b99 in update_light (ctx=0x805e208) at r200_state.c:1143
> > 1143 for (p = 0 ; p < MAX_LIGHTS; p++) {
>
> That doesn'
David Bronaugh wrote:
A device driver is not just a wrapper around the device which gives you
access to the registers. Even the core components of your computer have
a nice interface (your harddisk controller: open/read/write/close etc).
You're speaking of a generic interface to the hardware. The
Tomas Carnecky wrote:
Ian Romanick wrote:
Tomas Carnecky wrote:
The dri/drm interface seems to be quite low-level. I heard somewhere
that different devices have quite different registers and work in a
quite different way. If it is true that it would be better to make a
more high-level interface whe
The design priciple of the open-source drivers is that the kernel part
acts as nothing more than a conduit to shove bits into the chip.
It's the first time I hear that.
It is a good design principle for hardware with complicated interface.
Because of that, the interface is pretty raw and varies
Ian Romanick wrote:
Tomas Carnecky wrote:
The dri/drm interface seems to be quite low-level. I heard somewhere
that different devices have quite different registers and work in a
quite different way. If it is true that it would be better to make a
more high-level interface where every driver can do
Tomas Carnecky wrote:
The dri/drm interface seems to be quite low-level. I heard somewhere
that different devices have quite different registers and work in a
quite different way. If it is true that it would be better to make a
more high-level interface where every driver can do it's stuff as it
ne
The dri/drm interface seems to be quite low-level. I heard somewhere
that different devices have quite different registers and work in a
quite different way. If it is true that it would be better to make a
more high-level interface where every driver can do it's stuff as it
needs. How much low/high
As it seems, there is the required code for managment of drawables
within the drivers, but noone seems to use it (drm_drawable.h).
Any reason for that? (I mean for not using it).
--
wereHamster a.k.a. Tom Carnecky Emmen, Switzerland
(GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?
Tomas Carnecky wrote:
Ian Romanick wrote:
Tomas Carnecky wrote:
Why are the DRM() macros used in the linux kernel drivers?
I'm sure this has been discussed many times, but I can't find
anything about it.
Any explanations or pointers to webpages (archives) where it's
explained are welcome.
Each DRM
Ian Romanick wrote:
Tomas Carnecky wrote:
Why are the DRM() macros used in the linux kernel drivers?
I'm sure this has been discussed many times, but I can't find
anything about it.
Any explanations or pointers to webpages (archives) where it's
explained are welcome.
Each DRM driver contains a sli
Tomas Carnecky wrote:
Why are the DRM() macros used in the linux kernel drivers?
I'm sure this has been discussed many times, but I can't find
anything about it.
Any explanations or pointers to webpages (archives) where it's
explained are welcome.
Each DRM driver contains a slightly customized copy
As tehre are no debian specific remarksections the Makefile dose support
Debian. There is no make install function thought.
--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> The current dri.freedesktop.org:/cvs/dri/drm/Makefile is missing support
> for debian. What I found shoking is that there is s
Why are the DRM() macros used in the linux kernel drivers?
I'm sure this has been discussed many times, but I can't find
anything about it.
Any explanations or pointers to webpages (archives) where it's
explained are welcome.
Thanks
--
wereHamster a.k.a. Tom Carnecky Emmen, Switzerland
(GC 3.1) G
The current dri.freedesktop.org:/cvs/dri/drm/Makefile is missing support
for debian. What I found shoking is that there is support for SuSE, as
well as RedHat. I don't think it's at all whise to duplicate this work.
Surely there is an autoconf ./configure script that will detect the
distribution
>> Is there savage guide with lspci names and numbers (TwisterK
>> 5553:8d02 (rev 01)
>> etc) for cards?
>take a look a the savage DDX (2d driver). it should give you a pretty
>good idea of which chips fall into which categories.
>Also my savage guid should give a you a general idea:
>http://www.
On Wed, 26 May 2004, Keith Whitwell wrote:
Vladimir Dergachev wrote:
Hi Nikolai,
I merged your patches - thank you very much !
I wonder if a similar approach could allow us to reset the radeon/r200 after
lockups?
Well, Nikolai's patch is not specific to R300 - it uses plain Radeon
registers.
Attached is a screen shoot of the effect of adding 1024 to the
ColorOffset. I still have to find where rmesa->state.color.drawOffset
comes from and what effect the first 4 bits(define RADEON_COLOROFFSET_MASK
0xfff0) are for(Why "& RADEON_COLOROFFSET_MASK" was missing from
_lock.c and _ioc
Vladimir Dergachev wrote:
Hi Nikolai,
I merged your patches - thank you very much !
I wonder if a similar approach could allow us to reset the radeon/r200 after
lockups?
There's historically been code which tried to do that, but it just never ever
worked...
Keith
24 matches
Mail list logo
