This is a first pass at the three new IOCTL patch.
It is against the DRM copy in the Mesa tree. Building DRM from mesa works fine.
It includes the radeon mode setting IOCTL.
1) It is 2.6 only since it has sysfs and hotplug support. I will need to add
ifdef's to remove these on 2.4.
2) It uses the
Around 18 o'clock on Mar 13, Jon Smirl wrote:
> This is true. Software Mesa can completely emulate everything and just use a
> dumb framebuffer for output. The DRM driver for a dumb framebuffer is pretty
> simple to write. For the smallest possible system restrict yourself to
> OpenGL-ES, statica
I have been able to reproduce several x server crashes by killing a
process from tty 1,2 or 3 that is running on tty5 this crash occurs
after killing a variety of process such as evolution and mozilla and
then attempting to switch to tty5 from tty 1,2 or 3. I am running
XFree86 Version 4.3.0 (DRI
Here's three more ideas I'm thinking about but I haven't written any code for...
First some terminology. We really have two consoles. There is the kernel console
that gets the printk output. Second is a user console that you can log into.
Right now the fbconsole system maps these to the same plac
On Sat, 2004-03-13 at 17:35, Jon Smirl wrote:
> --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > On Sat, 2004-03-13 at 04:54, Jon Smirl wrote:
> > >
> > > A fourth call will be a driver specific call for setting the video mode. I
> > am
> > > implementing this by completely computing the register v
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
Ian Romanick wrote:
[...]
Here an extract from my logfile:
(==) RADEON(0): Write-combining range (0xe000,0x200)
(II) RADEON(0): Wrote: rd=6, fd=58, pd=2
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sat, 2004-03-13 at 04:54, Jon Smirl wrote:
> >
> > The code for the proposed IOCTLs is written and tested. They would be added
> one
> > at a time.
>
> Do you have a patch for us to look at?
I'll start sending the patches out if everyone is ok w
On Fri, Mar 12, 2004 at 03:39:50PM -0800, Alex Deucher wrote:
> > > As I recall the G450-PCI cards were just AGP chips with an agp to
> > pci
> > > bridge. Perhaps you need to hack up an agpgart driver for the
> > bridge?
> > > Also, for the pci g450, matrox only supported 3D on motherboards
> >
On Fri, Mar 12, 2004 at 01:40:30PM -0800, Ian Romanick wrote:
>
> I want to initially support this by just "disabling" AGP texturing. I
> looked in the DRI driver, and it looks like this can be done with some
> trivial changes in mga_xmesa.c. Basically, the code just needs to
> handle the cas
On Sat, 2004-03-13 at 04:54, Jon Smirl wrote:
>
> The code for the proposed IOCTLs is written and tested. They would be added one
> at a time.
Do you have a patch for us to look at?
> 3) BLANK - simple call to allow Vesa power management to blank the display.
>
> A fourth call will be a drive
On Fri, 2004-03-12 at 20:34, Ian Romanick wrote:
> Jon Smirl wrote:
>
> > Sorry I broke the DRI build, now I see what the problem is. When the Mesa is
> > included in the DRI tree is it is using the DRM driver in the DRI tree. I didn't
> > know that the DRI build would alter the Mesa include paths
sorry, I'm still waiting for someone to tell me exactly how I do what is described
here, to stop getting the rainbow stuff.
Do i disable this in XF86Config or something?
--- On Wed 03/10, Michel =?ISO-8859-1?Q?D=E4nzer?= < [EMAIL PROTECTED] > wrote:
From: Michel =?ISO-8859-1?Q?D=E4n
13 matches
Mail list logo
