Alex Deucher wrote:
--- Thomas Hellstrom [EMAIL PROTECTED] wrote:
Hi!
Via have, some time ago, released a drm module which seems quite
clean
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
Jon Smirl wrote:
This patch switches the dri build over to use the new standalone drm tree.
You will need to check out the new drm tree from the dri CVS root
Apply the patch to dri
DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the
drm tree
You will also need to fix
On Wed, Mar 17, 2004 at 09:14:52AM +, Keith Whitwell wrote:
Jon Smirl wrote:
This patch switches the dri build over to use the new standalone drm tree.
You will need to check out the new drm tree from the dri CVS root
Apply the patch to dri
DRMSrcDir in config/cf/host.def needs to be
Ian Romanick wrote:
I spent some time today pulling the DRI interface structures and
function prototypes out of glxclient.h. I came across one snag that I
missed before. It turns out that the bindContext2 and unbindContext2
methods in __DRIcontextRec are passed pointers to GLXContext
On Tue, 16 Mar 2004 16:31:37 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
I spent some time today pulling the DRI interface structures and
function prototypes out of glxclient.h. I came across one snag that I
missed before. It turns out that the bindContext2 and unbindContext2
methods in
On Wed, 17 Mar 2004 01:09:09 +0100
Arkadiusz Miskiewicz [EMAIL PROTECTED] wrote:
Hi,
I wanted to test new savage dri on my laptop - it has
01:00.0 VGA compatible controller: S3 Inc. VT8636A [ProSavage KN133] AGP4X VGA
Controller (TwisterK) (rev 01)
I've used 2.6.4 kernel + XFree86 4.4.0
I mostly kept out of this discussion, so I may not quite be up-to-speed.
Feel free to ignore my comments.
On Tue, 16 Mar 2004 20:06:32 -0800 (PST)
Jon Smirl [EMAIL PROTECTED] wrote:
This patch switches the dri build over to use the new standalone drm tree.
You will need to check out the new
Michel Dnzer wrote:
On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote:
Jon Smirl wrote:
This patch switches the dri build over to use the new standalone drm tree.
You will need to check out the new drm tree from the dri CVS root
Apply the patch to dri
DRMSrcDir in config/cf/host.def needs to be
On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote:
Jon Smirl wrote:
This patch switches the dri build over to use the new standalone drm tree.
You will need to check out the new drm tree from the dri CVS root
Apply the patch to dri
DRMSrcDir in config/cf/host.def needs to be edited to
Alex Deucher wrote:
--- Thomas Hellstrom [EMAIL PROTECTED] wrote:
Hi!
Via have, some time ago, released a drm module which seems quite
clean
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
On Wed, 2004-03-17 at 13:23, Keith Whitwell wrote:
Michel Dnzer wrote:
On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote:
Jon Smirl wrote:
After the switch I can remove these directories from dri:
/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
--- Thomas Hellström [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
--- Thomas Hellstrom [EMAIL PROTECTED] wrote:
Hi!
Via have, some time ago, released a drm module which seems quite
clean
and a dri / OpenGL implementation which Alan Cox fixed up some
time
ago
and which is
On Wed, 2004-03-17 at 13:46, Thomas Hellstrm wrote:
What's important for us currently is to have an _official_ drm module
available in dri cvs to base our Xfree86 2d XvMC component development on,
so there won't be different customized via drm modules circling around as
kernel patches. The
--- Thomas Hellström [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
--- Thomas Hellstrom [EMAIL PROTECTED] wrote:
Hi!
Via have, some time ago, released a drm module which seems quite
clean
and a dri / OpenGL implementation which Alan Cox fixed up some
time
ago
and which is
--- Felix Kühling [EMAIL PROTECTED] wrote:
On Tue, 16 Mar 2004 16:31:37 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
I spent some time today pulling the DRI interface structures and
function prototypes out of glxclient.h. I came across one snag
that I
missed before. It turns out
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Wed, 2004-03-17 at 13:23, Keith Whitwell wrote:
Michel Dänzer wrote:
On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote:
Jon Smirl wrote:
After the switch I can remove these directories from dri:
On Wed, Mar 17, 2004 at 09:07:12AM -0800, Jon Smirl wrote:
--- Alan Hourihane [EMAIL PROTECTED] wrote:
I'd also like to mention that the Imakefile's or Makefile.linux/bsd will
still need to be in some form in these three directories.
I think I've fixed all the directory permissions now. Give it try and let me
know.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
--- Felix Kühling [EMAIL PROTECTED] wrote:
Hmm, the savage driver uses GLuint when it actually means a 32 bit word
in the register definitions. Where does int32_t come from? Would it be
the right type to use in that case? Is there also a uint32_t?
They come form the standard C header file
Michel Dnzer wrote:
Jon Smirl wrote:
dri branches will also need to apply this patch
Why? What happens on the trunk shouldn't affect them. That's the point
of a branch. :)
I believe the intention is to *move* the ,v files. If that happens, the
files will disappear from all branches. That said,
Keith Whitwell wrote:
Ian Romanick wrote:
There also seem to be some issues with drivers using CARD32. That
type comes from X, so it should probably be replaced with something
window-system agnostic. Would int32_t work for everyone?
I think this is the best we can do, though at least some
--- Ian Romanick [EMAIL PROTECTED] wrote:
Another question. dri_util.[ch] will need to be moved from DRI CVS to
Mesa CVS. Is it possible to copy the ,v files from one project to another?
I just copied v files from mesa into dri/drm and it seems to work.
Check the videro-reset files in the
On Wednesday 17 March 2004 05:12, Felix Kühling wrote:
dri branches will also need to apply this patch
I don't like that. Can branches still keep their own copy of the old
DRM? I'm particulary thinking of the s3virge branch which is
unmaintained at the moment. I'm not sure if it even
Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
There also seem to be some issues with drivers using CARD32. That
type comes from X, so it should probably be replaced with something
window-system agnostic. Would int32_t work for everyone?
I think this is the best we can do,
ajax wrote:
On Wednesday 17 March 2004 05:12, Felix Kühling wrote:
dri branches will also need to apply this patch
I don't like that. Can branches still keep their own copy of the old
DRM? I'm particulary thinking of the s3virge branch which is
unmaintained at the moment. I'm not sure if it even
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 correct. I didn't have
First let me say that if you only have one video card installed you don't see
this.
If you have two or more video cards you will find that the system BIOS only
resets one of them. X contains some really ugly user space code that resets
these cards. This code does things like play with PCI bridge
On Wed, 17 Mar 2004 09:46:30 -0800 (PST)
Jon Smirl [EMAIL PROTECTED] wrote:
I am copying the v files. The branches get impact via single file symlinks as I
explained in
other mail.
Only branches which use the external DRM. Branches that still have their
own internal one should not be
On Wednesday 17 March 2004 13:03, Keith Whitwell wrote:
I think CVSBranches on the wiki needs to be reorganized into several
sections (current, sleeping, and obsolete) to reflect this; current would
stay about the same, sleeping would be things like savage and s3virge,
and obsolete would
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 fix
--- Alan Cox [EMAIL PROTECTED] wrote:
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
On Wed, 17 Mar 2004 12:21:36 -0600
ajax [EMAIL PROTECTED] wrote:
On Wednesday 17 March 2004 05:12, Felix Kühling wrote:
dri branches will also need to apply this patch
I don't like that. Can branches still keep their own copy of the old
DRM? I'm particulary thinking of the s3virge
Jon Smirl wrote:
This patch switches the dri build over to use the new standalone drm tree.
You will need to check out the new drm tree from the dri CVS root
Apply the patch to dri
DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the
drm tree
Should the user-space
The solo version of this is in Mesa/src/glx/mini. It will need to be adjusted to
track whereever the X version ends up. It might even be possible to eliminate
the solo version.
--- Ian Romanick [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
This patch switches the dri build over to use the new
I am having difficulty compiling the DRI tree.I have done this
successfully several times in the past. I downloaded the snapshot from
the CVS listed here http://dri.sourceforge.net/cgi-bin/moin.cgi/Download
and edited the host.def file to point to the mesa source libs I
downloaded from here
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
Hi!
Here comes the via drm module patch against current (at least as of
today :-) CVS
(/usr/local/src/dri-cvs/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm)
What we've done is the following:
1. Base. Via:s drm Module 0038.
2. Added vblank_wait IOCTL support (Terry Barnaby), via_irq.c
I think I've fixed all the directory permissions now. Give it try and let me
know.
--- Keith Whitwell [EMAIL PROTECTED] wrote:
cvs checkout: Updating drm/bsd/drm
cvs checkout: failed to create lock directory for `/cvs/dri/drm/bsd/drm'
(/cvs/dri/drm/bsd/drm/#cvs.lock): Permission denied
cvs
Patrick Dohman wrote:
I am having difficulty compiling the DRI tree.I have done this
successfully several times in the past. I downloaded the snapshot from
the CVS listed here http://dri.sourceforge.net/cgi-bin/moin.cgi/Download
and edited the host.def file to point to the mesa source libs I
I am copying the v files. The branches get impact via single file symlinks as I
explained in
other mail.
After the switch I will use cvs rm on them.
--- Ian Romanick [EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
Jon Smirl wrote:
dri branches will also need to apply this patch
Why?
--- Alan Cox [EMAIL PROTECTED] wrote:
Certain ACPI things need video setup too, and btw I for one agree with
you about something - for some cards the video reset being handled via
hotplug actually may make sense.
I'm just trying to get a first pass at this code checked in the new drm tree. I
Have every one tried the patch I sent out for switching the dri tree over to the
new drm?
Are there objections to doing the switch over later tonight?
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
On Wed, 2004-03-17 at 19:10, Ian Romanick wrote:
Another question. dri_util.[ch] will need to be moved from DRI CVS to
Mesa CVS. Is it possible to copy the ,v files from one project to another?
Theoretically yes, but won't this cause the files to appear in checkouts
of earlier revisions of
On Thu, 2004-03-18 at 01:00, Jon Smirl wrote:
An even better solution would be for the kernel itself to call the VBIOS ROMs
during very early boot before entering protected mode. But someone with more
experience in the early kernel boot process needs to trying implementing it that
way.
On Wed, 2004-03-17 at 20:40, Jon Smirl wrote:
To me the video-reset program is an extension of the DRM device driver and
should be kept in the new drm tree. But other people have different opinions.
Well, I'm the one who tried to talk you out of this on IRC. :) And I
thought I had succeeded,
I'm tried of fighting with you over every little change. So you win. You can be
in charge of moving the tree around and doing the merges however you want. I
leave for three weeks in Hawaii in two days anyway so I really don't care what
you do.
You have the patch for swithing the tree over, commit
--- Alan Hourihane [EMAIL PROTECTED] wrote:
May I suggest you provide an Imakefile that does what your suggesting ?
Already did. The patch I sent out works that way for drm.
Alan.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail - More
On Mon, 2004-03-15 at 10:08, Ian Romanick wrote:
Patrick Dohman wrote:
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
Just a side note, is the history of these files needed in the mesa tree?
I would think it would only be uasable in the DRI tree and it's archived
there so no need to duplicate that.
The DRM is another storry, ppl may wish to build older versions from the
new module.
--- Michel Dänzer [EMAIL
--- Alan Hourihane [EMAIL PROTECTED] wrote:
I'd also like to mention that the Imakefile's or Makefile.linux/bsd will
still need to be in some form in these three directories.
xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
50 matches
Mail list logo
