made using
pci_alloc_consistent in the init function surviving over a suspend. The
impression I got from asking people was that a DMA mapping such as that
would -not- survive a suspend cycle.
Info / feedback welcome :)
David Bronaugh
---
This SF
Nonetheless, a definite improvement with i915 driver from before
(suspend and resume with i830 DRI would suspend fine, but resume would
lead to a hung machine after X restarted).
David Bronaugh
---
This SF.net email is sponsored by: IT Product Guide
A, or am I not keeping up with the C
standard changes?
Had some crashes on Irix back in the early 90's related to this :)
Short circuit evaluation rules apply. A will be evaluated first; if it
is false, B will not be evaluated.
Hope this clears things up.
David Bronaugh
-
uld happen,
since ACPI could affect graphics state in some pretty hairy ways. It
might be a good idea to get in contact with him before the user emails
show up...
David Bronaugh
ps: I kinda trimmed the CC: list on this
---
This SF.Net email is
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 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
ere dose not appere to be a config option for what
monitor is used when going FS.
It seems to me like there needs to be some kind of an abstraction
between physical CRTCs and displays.
I don't know what it should be; just an observation.
David Bronaugh
Ville Syrjälä wrote:
On Sun, May 16, 2004 at 08:08:10PM -0700, David Bronaugh wrote:
Vladimir Dergachev wrote:
This brings out an interesting memory management point: swappable versus
non-swappable graphics objects.
A framebuffer is obviously non-swappable, while textures are swappable
Vladimir Dergachev wrote:
On Sun, 16 May 2004, David Bronaugh wrote:
Vladimir Dergachev wrote:
Yes, I think the mode/dac programing code should be seperat from the
frambuffer allocation/mngmnt code. Wather it should live in the
DRM is
another story, thought It should live kernel side as it
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
I think this design allows for mergedfb t
d of course add a few more failure conditions -- if the
framebuffer's virtual is less than the mode you're trying to set, it'll
fail -- and so on. But overall, I like it :)
David Bronaugh
---
This SF.Net email is sponsored by: Sourc
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
Mike Mestnik wrote:
This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be
Mike Mestnik wrote:
Let me start of by saying I think you are on the right track and all of
your ideas look good.
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
Mike Mestnik wrote:
This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
Ho
, and 3D graphics -- it's
about bootstrapping a usable mode. After the mode's boostrapped, you can
do whatever you want with framebuffers -- if you want more buffers, call
another ioctl to request them. At least in my opinion, it is not part of
mode setting.
If you have good reasons wh
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
- Format of messages might be something like device identifier,
resx, resy, colour depth, refresh (optional), extra_params (optional)
Did you talk at all about memory mngmt? For instance when setting a mode
David Bronaugh wrote:
Anyhow... to recap the ideas thus far:
I'm going to elaborate considerably at this point, probably dragging in
lots of stuff no one wants to see in here, etc -- all to try and figure
out what's wanted/needed. The following is about the mode setter itself.
Egbert Eich wrote:
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 nee
Egbert Eich wrote:
David Bronaugh writes:
> Egbert Eich wrote:
>
> >I don't only want to see mode selection in user land but also mode
> >programming.
> >I keep reiterating the reasons:
> >
> >1. Mode programming for a number of chips needs to be done
David Bronaugh wrote:
You could simply pass something like this (using an arbitrary text
format) to userspace:
radeon:1024x768
and have it set the best-match mode. The 'radeon' part, of course,
would make sure that the wrong code wasn't used. Likewise, the
userspace program c
format) to userspace:
radeon:1024x768
and have it set the best-match mode. The 'radeon' part, of course, would
make sure that the wrong code wasn't used. Likewise, the userspace
program could be fed any data it needed this way.
Anyhow, just an idea. No idea if
Roberto Pariset wrote:
mmm so can i fix it somehow or just wait for a new deb? isnt SSE a cpu
flag? if so i /proc/cpuinfo says i have it (amd xp 1600+). thanks
rob
Il lun, 2004-03-08 alle 22:57, David Bronaugh ha scritto:
I think this has been covered about a million times.. the SIGFPU is
tion.
I think this has been covered about a million times.. the SIGFPU is
caused by the test for SSE.
David Bronaugh
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO
omes to mind.. older iBooks had r128.
David Bronaugh
Alex
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5
interface; it'll perform like crap no matter how good the drivers are.
David Bronaugh
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code?
ought from a non-developer.
David Bronaugh
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win
properly_ -- do NOT do this before) you can set the AGP
mode, as well as enabling page flipping. I'm not going to tell you how
to do this; there's plenty of documentation out there, and it's not
strictly necessary.
Good luck!
David Bronaugh
-
I was told
> the i740 had US military secret stuff stamped all over it still
I searched Google.
Here's the result I got:
ftp://download.intel.com/support/graphics/intel740/29061902.pdf
Looks like a pretty full spec to me. Hopefully it is.
David Bronaugh
ps: I'm thinking about writing
nds on what the aim is -- more 3D drivers under Linux that
use DRI, or fewer ones that are open source
Comments?
David Bronaugh
pgp0.pgp
Description: PGP signature
o make of it.
Screenshot: (1280x1024, sorry, my flat panel made me do it! I swear!)
http://bronaugh.linuxboxen.org/q3_glitch.jpg
I got this with trunk too, without this patch. Hopefully I'm not hitting a hardware
flaw or such in my card (ie, bad ram)...
It seems to change a lot with mo
gured an
unsupported card might be a good avenue.
David Bronaugh
---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use bro
se it's not at all complete.
It's merely an interface to the kernel from a binary object in the case of the kernel
driver -- and don't forget, their glx differs too, and for THAT there is _no_ source
code.
Why hasn't it been done? Beca
n 1fps. He didn't
have the patience to get into the game.
Apparently there were also some artifacts in 2d, but those are of less concern.
Anyhow, that's what I have to report there.
David Bronaugh
---
This sf.net email is sponsored
the major rendering glitch with the mach64 on the walls - the
texture just isn't integrated as it should be.
Also, there's no mipmapping, but that's less of an issue.
Any ideas? I'd love to help here, but I don't know where
Is the mach64 code based on X 4.2.0? Is it based on X CVS?
I'd like to know so I can build it properly here, and not bork up.
David Bronaugh
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
ose,
I appreciate your work on the mach64 -- there is now what I would say is decent
hardware OpenGL support on it.
Now, I'd love to see the 2D engine running too... *grin*. Could you tell me what's
entailed to get that going?
David Bronaugh
> Well, I hope this degenerates in a l
fiable. They
aren't just straight ASICs.
David Bronaugh
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
ormed under any operating system other than that which was on the floppy).
This doesn't support your conclusions here. I would hazard a guess that memory
performance there had more to do with the chipset involved than superior memory
technology.
David Bronaugh
___
I'm using an older version of the mach64 code, but I also get this. Perhaps there's an
issue with the Z buffer or such? I don't know a lot but that sounds probable if it's
not being consistently drawn.
Rage Mobility P/M here on a Toshiba Satellite 1750
not (if so, great), but here's a link to them:
http://www.ati.com/support/drivers/win98/win984122632.html
If you aren't, maybe you'll gain some insight from this.
David Bronaugh
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://li
I know that at least in quake3 with my Rage Mobility P/M chip in my
laptop, lightmap lighting doesn't work. I am not sure if this is peculiar
to my setup (I just thought, hey, it's a crappy old chip) but it might be
relevant to the UT problem (I think UT is big on lightmap lightin
ns they have a linear power regulator -
many don't supply enough power to run new cards.
David Bronaugh
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
> From: David Bronaugh <[EMAIL PROTECTED]>
> Date: 2002-01-17 23:11:46
>
>
> >Perhaps a good idea here would be to have some sort of a function
> >documentation tracking project.. I have been doing a hell of a lot of
> PHP
>
> See above
one wants me to do this, I have a machine to
host it on, and I'd be willing to put in the time to develop this. Just
send me an email and/or gimme a holler on the list about ideas, etc.
David Bronaugh
--- End Message ---
like to see 3D working on. Usually, it'd be rather
difficult to desolder one of those nice 300 pin surface mount chips and
solder another one on, even if it were pin compatible (yeah, right...).
Basically, we'd like to see 3D work on these laptops. At least we don't
have those Tride
ple" that users rely upon for advice. What card will we
suggest, a card whose manufacturer actively supports linux, or a
manufacturer that's like SiS? Once you take this factor into account,
there's a completely different kind of analysis needed.
David Bronaugh
_
don't know if it's relevant (or even safe, registers could
change and not be restored), but so far as I can see it could really help
with devel time.
David Bronaugh
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Hi,
I'm interested in perhaps working on ATI Rage Pro support under DRI. I
understand some work has been done on it, but it has been going slowly.
Can someone tell me the status of that work, and where to get whatever code
has been done?
(is it in CVS?)
David Bronaugh
--
Begin Ec
47 matches
Mail list logo
