> > Or is the installed 64-bit user base small enough that we
> > can make them take one for the team, so to speak?
>
> With cheap 64-bit processors coming out from AMD and
> Intel the base is growing faster than ever, so better
> get on with it yesterday :)
>
> --j
>
with that in
On Wed, 12 May 2004, Ian Romanick wrote:
> Or is the installed 64-bit user base small enough that we
> can make them take one for the team, so to speak?
With cheap 64-bit processors coming out from AMD and
Intel the base is growing faster than ever, so better
get on with it yesterday :)
Around 9 o'clock on May 12, Keith Whitwell wrote:
> My one worry about the discussion is that because of confusion over where the
> X developers are hanging out nowadays, they are missing out on having their
> say on this - and they probably care deeply about modesetting.
Egbert and I are here
On Tue, 2004-05-11 at 16:34, [EMAIL PROTECTED] wrote:
> On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said:
>
> > I just looked at drm.h and nearly all the ioctls use int, this file is
> > included in user-space applications also at the moment, I'm worried
> > changing all ints to __u32 will break
--- 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 of months back both you and Linus called me
insane. I need to go find those posts.
T
Ian Romanick wrote:
Roland Scheidegger wrote:
Ah, missed that in the spec. Seems to be unnecessarily restrictive
to not have a weighting factor for GL_MIN/MAX, apparently common
hardware could do it just fine (or maybe it doesn't make enough
sense to allow it?).
Modern hardware can, but that exte
cvs -d:[EMAIL PROTECTED]:/cvs/mesa co drm
it is in the video reset directory.
you will need to modify it a little for command line use since it is meant to be
called from a hotplug event
--- Richard Smith <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > licenses). I've already built a very mes
> is the installed 64-bit user base small enough that we can make them take one
> for the team, so to speak?
yeah I'm getting the feeling a flag day may be necessary
---
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-u
Hey all,
I've been following the discussion on driver simplification, and I'm not
quite sure I understand everything that has been said. As I understand
it, you are trying to make kernel drivers just init the hardware, and
provide hooks for userspace software to drive the hardware themselves?
(ie
Linus Torvalds wrote:
On Wed, 12 May 2004, Dave Airlie wrote:
I just looked at drm.h and nearly all the ioctls use int, this file is
included in user-space applications also at the moment, I'm worried
changing all ints to __u32 will break some of these, anyone on DRI list
care to comment?
Right no
> What this is saying is that very early in the boot process the graphics driver
> will be initialized. At this point it will generate a hotplug event. This event
> will be handled by an app and lib that live in initramfs. This is not saying
> that mode-setting will be delayed until normal user s
> > That app must be pretty big if it runs on non intel platforms. You nedd to
> > translate the x86 BIOS code to native assembly before you run it.
>
> Or interprete it.
Only if we could use Java for the video BIOS.
---
This SF.Net email i
On Wed, 12 May 2004, James Simmons wrote:
> I understand you point of the mode switching code being huge. The embedded
> guys require really lean kernels. I have no problem making the mode switching
> code modular. I just want to avoid the above overhead.
And for an embedded device with a fixed LC
> Anyway. I've got a lot of respect for the people involved in the discussion,
> even when they hold quite conflicting views, so I'm hopeful that some sort of
> direction can be reached for moving forward.
I apologize for getting over heated. I'm very protective of the companies
that work i
On Wed, 12 May 2004, James Simmons wrote:
> > > That app must be pretty big if it runs on non intel platforms. You nedd to
> > > translate the x86 BIOS code to native assembly before you run it.
> >
> > Or interprete it.
>
> Only if we could use Java for the video BIOS.
Java? em86 (written by Gabr
On Wed, 12 May 2004, James Simmons wrote:
> That app must be pretty big if it runs on non intel platforms. You nedd to
> translate the x86 BIOS code to native assembly before you run it.
Or interprete it.
> On Wed, 12 May 2004, Richard Smith wrote:
> > Jon Smirl wrote:
> > > licenses). I've alrea
Alan Cox writes:
>
> In which case bank switch is needed. Its actually not clear you need
> 2D accel. Its *nice* but not essential. Its becoming more and more the
> case that console mode is the debug/boot interface for a device.
OK.
>
> > (I'n not talking about
> > VGA banking, but it se
> > > > That app must be pretty big if it runs on non intel platforms. You nedd to
> > > > translate the x86 BIOS code to native assembly before you run it.
> > >
> > > Or interprete it.
> >
> > Only if we could use Java for the video BIOS.
>
> Java? em86 (written by Gabriel Paubert) has been wor
James Simmons wrote:
That app must be pretty big if it runs on non intel platforms. You nedd to
translate the x86 BIOS code to native assembly before you run it.
Or you emulate thier functionality.. but perhaps thats what you are
saying. Thats what X does. LinuxBIOS has pulled the x86emu out i
That app must be pretty big if it runs on non intel platforms. You nedd to
translate the x86 BIOS code to native assembly before you run it.
On Wed, 12 May 2004, Richard Smith wrote:
> Jon Smirl wrote:
>
> > licenses). I've already built a very messy prototype by moving the existing
> > fbdev
On Tue, May 11, 2004 at 08:30:45PM -0700, Jon Smirl wrote:
[...]
> So moving mode setting to user space is not the end of the world. Everything
> will still work. This is more like a monolithic vs microkernel type of decision.
Which is why Linux is a monolithic kernel, it's by design. The net is
On Wed, 12 May 2004, Dave Airlie wrote:
>
> I just looked at drm.h and nearly all the ioctls use int, this file is
> included in user-space applications also at the moment, I'm worried
> changing all ints to __u32 will break some of these, anyone on DRI list
> care to comment?
Right now, all ar
Hi, Getting there with the process of
getting all the VIA stuff working. Using 2.4.24-epia1 kernel and XF86 4.4, and
got X working with the VIA driver as below. XFree86 Version 4.4.0
Release Date: 29 February 2004 X Protocol Version 11, Revision 0,
Release 6.6 Build Operating System: Linux
Roland Scheidegger wrote:
Ian Romanick wrote:
Roland Scheidegger wrote:
this new demo fails pretty horribly on r200. It seems to be caused
by the same bug as I reported here,
http://marc.theaimsgroup.com/?l=dri-devel&m=107854279829216&w=2,
something fundamental just doesn't work right with regar
SunWave1 progs/demos# ./gears
Mesa: software DXTn compression/decompression available
Speicherschutzverletzung (core dumped)
Reading symbols from /usr/X11R6/lib/libXt.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXt.so.6
Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done.
Loade
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
Ian Romanick wrote:
Roland Scheidegger wrote:
this new demo fails pretty horribly on r200. It seems to be caused
by the same bug as I reported here,
http://marc.theaimsgroup.com/?l=dri-devel&m=107854279829216&w=2,
something fundamental just doesn't work right with regard to
blending. Even if you
>I thought about this a bit more. Let me propose a different viewpoint
as
>a result. That viewpoint is that there is no reason for any
>acceleration. Scroll at most.
>
>If the video mode switching is done right and apps can handle graphics
>nicely then you need a kernel mode text console at boot,
Roland Scheidegger wrote:
this new demo fails pretty horribly on r200.
It seems to be caused by the same bug as I reported here,
http://marc.theaimsgroup.com/?l=dri-devel&m=107854279829216&w=2,
something fundamental just doesn't work right with regard to blending.
Even if you never enable blendi
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
this new demo fails pretty horribly on r200.
It seems to be caused by the same bug as I reported here,
http://marc.theaimsgroup.com/?l=dri-devel&m=107854279829216&w=2,
something fundamental just doesn't work right with regard to blending.
Even if you never enable blending (or disable it explicitl
Dave Airlie wrote:
Ick, you can't use "int" as an ioctl structure member, sorry. Please
use the proper "__u16" or "__u32" value instead.
I just looked at drm.h and nearly all the ioctls use int, this file is
included in user-space applications also at the moment, I'm worried
changing all ints to
Jerome Glisse wrote:
Sorry for cross posting but i got a little question :)
DRI use the mesa cvs for a part of this drivers right now ?
isn't it ? If so please review my patch that intend to
correct compilation warning (most of my patch simply add
type cast to avoid warning)
For the DRI patch : ---
Jon Smirl wrote:
licenses). I've already built a very messy prototype by moving the existing
fbdev code to user space and it works just fine. I also called another little
app which executed the VBIOS and reset secondary cards at boot via hotplug.
Is that app available somewhere? I'm trying to get
David Bronaugh writes:
> Egbert Eich wrote:
> >
> >I don't think you want to call user mode code from inside the kernel.
> >The kernel could take a passive role and use the mode that a userland
> >program tells it is set. If all the kernel needs is a linear freambuffer
> >of size x * y and de
sottek writes:
> Can we wrap this up the discussion and try to get to a consensus on
> design requirements? I think most of the opinions are starting to
> solidify enough to start hashing out the requirements and actual
> design.
>
> Also, we probably want to drop the communication down to j
On Tue, 2004-05-11 at 20:09, sottek wrote:
> Can we wrap this up the discussion and try to get to a consensus on
> design requirements? I think most of the opinions are starting to
> solidify enough to start hashing out the requirements and actual
> design.
I agree, and I like your initial list o
Sottek, Matthew J writes:
>
> >Boy, I haven't really been following this too closely, but surely this
> >sort of thing can be resolved with an extension mechanism or api
> >versioning?
>
> An extension mechanism is fine for eventually extending the basic
> functionality, but a driver write
On Tue, May 11, 2004 at 04:43:29PM -0700, Greg KH wrote:
> On Tue, May 11, 2004 at 07:34:39PM -0400, [EMAIL PROTECTED] wrote:
> > On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said:
> >
> > > I just looked at drm.h and nearly all the ioctls use int, this file is
> > > included in user-space applic
On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said:
> I just looked at drm.h and nearly all the ioctls use int, this file is
> included in user-space applications also at the moment, I'm worried
> changing all ints to __u32 will break some of these, anyone on DRI list
> care to comment?
Is this a
On Tue, May 11, 2004 at 06:07:27PM -0700, Jon Smirl wrote:
> Would int16_t and int32_t work?
No, sorry. See the lkml archives for why.
> Those int's were in there before I started working on it. __u16 and
> __u32 are Linux kernel defines that aren't always there in user space.
Don't share heade
On Tue, May 11, 2004 at 07:34:39PM -0400, [EMAIL PROTECTED] wrote:
> On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said:
>
> > I just looked at drm.h and nearly all the ioctls use int, this file is
> > included in user-space applications also at the moment, I'm worried
> > changing all ints to __u
On Tue, May 11, 2004 at 08:07:09PM -0400, Daniel Jacobowitz wrote:
> On Tue, May 11, 2004 at 04:43:29PM -0700, Greg KH wrote:
> > On Tue, May 11, 2004 at 07:34:39PM -0400, [EMAIL PROTECTED] wrote:
> > > On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said:
> > >
> > > > I just looked at drm.h and ne
Ian Romanick wrote:
James Simmons wrote:
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. ("Basic" to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I
couldn't never win this figh
46 matches
Mail list logo
