On Iau, 2004-09-16 at 12:00, Dave Airlie wrote:
I'll apply this to my tree and fix up the rest of them in the DRM, and
push it to Linus..
Use __set_current_state() for these. set_current_state also includes a
memory barrier (ie its designed to be safe for all uses) while the DRI
code is already
On Mer, 2004-09-15 at 00:41, Jon Smirl wrote:
pci_enable/disable_device are correct in the dyn-minor patch. They
also appear to correct in the currently checked in DRM cvs. If fbdev
is loaded DRM does not do pci_enable/disable_device. It is assumed
that these calls are handled by the fbdev
On Mer, 2004-09-15 at 16:35, Jon Smirl wrote:
the video drivers vgacon still owns and is using it. On some devices
that needs PCI master enabled because of internal magic (like
rendering text modes from the bios via SMM traps)
How do I trigger this mode on a card supported by DRM so that
On Llu, 2004-09-13 at 18:50, Jon Smirl wrote:
How's this going to work with hotplug? Hotplug works by associating a
device with a driver by the PCI ID table contained in the driver. Both
the fbdev and DRI drivers currently contain the same PCI IDs for the
cards that the chipsets they support.
On Llu, 2004-09-13 at 23:51, Bjorn Helgaas wrote:
Add pci_enable_device()/pci_disable_device. In the past, drivers often worked
without this, but it is now required in order to route PCI interrupts
correctly.
This code is wrong. The DRI is only one user of the video card,
disabling the video
On Sul, 2004-09-12 at 23:42, Dave Airlie wrote:
The worst things that will happen for all concerened is this:
Jon does all this work on a merged solution outside the kernel, and it
works well, and the X team decide to do a decent X on mesa-solo on Jons
super-DRM, now the super-DRM gets pushed
On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
However, if we want the switch from X to framebuffer to be as fast as
switching between different text consoles (assuming they have the same
resolution) and if we want to be able to run different Xservers on
different consoles or
On Llu, 2004-09-13 at 16:06, Jon Smirl wrote:
It also needs something to sort out both drivers using pci_drvdata()
to get to their private data. For example in the hotplug routines you
only get passed a pdev and you want to use that to locate your private
data.
The hotplug routines for vga
On Llu, 2004-09-13 at 16:20, Vladimir Dergachev wrote:
It depends how the various components fit together. Clearly for Radeon
you want everyone using the DMA command path when DRI is loaded. That
doesn't require one driver
Alan, do I understand right that you are proposing to have two
On Llu, 2004-09-13 at 17:28, Jon Smirl wrote:
Doesn't the base platform need to be designed to also treat individual
heads as resources?
Already covered - although at the moment the question is open about who
tells the vga generic code It has 4 heads ?
Had a look over your class code - its
On Sul, 2004-09-12 at 12:36, Hamie wrote:
But this relies on drivers co-operating with each other.
Only minimally, and providing the co-operation is easy the rest comes
out fine. We don't often get ide-disk and ide-cd people arguing over
whose fault something is
Yeah. Would fglrx be more
On Sad, 2004-09-11 at 00:25, Jon Smirl wrote:
I need a major number for the VGA device.
Use one of the experimental ones (see Documentation/devices.txt). As and
if the driver becomes mainstream kernel material apply for one via
LANANA. I don't know what the *BSD procedures are.
On Sad, 2004-09-11 at 00:36, Jon Smirl wrote:
inter_module can't be removed until we move to the drm_core design
with personality modules
Of course it can go. You just fix up the DRI to start using
try_module_get(). Actually when you have the video class driver layer it
all comes for free
On Sad, 2004-09-11 at 00:24, Dave Airlie wrote:
stop saying this, it isn't true and hasn't been for years, for the mach64
type cards I'd agree, for something even like the i810 this isn't
Its true. Its still true whether you demand people stop saying it or
not.
true, most cards have two paths
On Sad, 2004-09-11 at 01:47, Vladimir Dergachev wrote:
One driver per device. I.e. one driver per *physical* device.
This is a religion the kernel doesn't follow. Its a pointless
religion
Lastly, one point that you appear to have missed: DRM does DMA transfers
(among everything else). FB
On Sad, 2004-09-11 at 01:50, Dave Airlie wrote:
So the IDE-CD driver and IDE-disk drivers both program registers on the
IDE controller directly.. oh no the ide driver seems to do that.. this is
FUD,
Its a shame the DRI people having nothing better to do than tell folks
to shut up or mutter FUD
On Sad, 2004-09-11 at 06:19, Dave Airlie wrote:
1. It doesn't matter where the code lives, fbdev/DRM need to start talking
about things
It matters immensely what the divison is because people talking doesn't
scale ..
I'm interested in seeing what Alan comes up with, even in a non-working
On Sad, 2004-09-11 at 08:11, Vladimir Dergachev wrote:
The thing is I know of no way to provide arbitration in such a way as to
permit other code to access PLL registers directly.
This arises solely because the DRM and framebuffer drivers cannot find
each other and have no shared structures.
On Sad, 2004-09-11 at 10:20, Antonino A. Daplas wrote:
In theory, one can have a process (kernel or userland) change the video
mode, then provide the in-kernel driver with the necessary information
about the layout of the framebuffer. When this in-kernel driver gets the
necessary information,
On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
My personal preference for this whole mess has always been the silly
driver that isn't even hardware-specific, and really does _nothing_ on
its own. This one would be the only thing that actually reserves the IO
regions and owns the card
On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
This is a good point - if we don't need DMA or 3d acceleration we can
reduce memory footprint. This would seem that current DRM driver would
need to be dependent on whatever driver contains the mode setting code.
What do you think ?
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
User 1's game queues up 20ms of 3D drawing commands.
Process swap to user 2. -quiesce() is going to take 20ms.
User 2's timeslice expires and we go back to user 1.
User 1 queues up another 20ms.
User 2's editor is never going to function.
If
On Sad, 2004-09-11 at 18:13, Jon Smirl wrote:
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
Card dependant.
How can you build a system that process swaps between these two modes?
The 3D pipeline has to be emptied before you can enter 2D immediate
mode.
My solution is to
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
User 1's game queues up 20ms of 3D drawing commands.
Process swap to user 2. -quiesce() is going to take 20ms.
User 2's timeslice expires and we go back to user 1.
User 1 queues up another 20ms.
User 2's editor is never going to function.
If
What about if you want to use fb when in text mode (Because you get
200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
back forth between X fb... (i.e. how I currently use it but with
On Sad, 2004-09-11 at 22:37, Jon Smirl wrote:
But since I've written most of the code so far I get to pick the
details of the implementation.
Umm thats what happened to ruby and thats what happened to KGI.
If Alan would instead like to pick the
details I've offered to withdraw if he'll
On Gwe, 2004-09-10 at 16:11, Jon Smirl wrote:
The plan is to add fbdev capability to the DRM so that you won't need
to run vesafb. DRM will give you the features found in VESA fb instead
of you needing to load it separately.
Your personal plan.
On Gwe, 2004-09-10 at 18:22, Jon Smirl wrote:
My personal plan has been posted for comment to all relevant email
lists -- xorg, fbdev, dri, and lkml. All feedback that was received
was addressed and incorporated. Various aspects of the plan were
Addressed and eliminated would be closer. The
PS: Don't get me wrong - we have to address the main points on that list
(the ones on the list not in your head). The last thing I want to see is
another person march off into the distance with a framebuffer agenda and
a lack of understanding about the importance of getting
from where we are now
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone addresses why it is acceptable to have
two separate driver driving the same
On Gwe, 2004-09-10 at 14:31, Felix Khling wrote:
The first region (frame buffer and apperture) is claimed (partially) by
vesafb, the second one (MMIO registers) is not claimed at all. I don't
see an obvious way to fix this.
Its already fixed in the stuff I'm working on. Given the list of all
On Gwe, 2004-09-10 at 22:56, Jon Smirl wrote:
drm.h should be located in /include/linux/ or /include/video instead
of /drivers/char/drm. The code for sharing the DRM major number with
the VGA device needs to pick some constants up out of drm.h. Can we
move it in the next kernel drop?
Ughhh.
On Gwe, 2004-09-10 at 22:30, Jon Smirl wrote:
No changes in the code, it's just regenerated against current DRM CVS
- drm_probe(pdev, DRM(pciidlist[i]));
+ DRM(probe)(pdev, DRM(pciidlist[i]));
Seems to revert macro clean up work.
+
On Sad, 2004-09-11 at 00:10, Jon Smirl wrote:
I'm counting on Ian to provide the memory management code. I haven't
even looked at it very much. The point is simply that we have to have
something, you just can't support multiple heads without minimal
memory management and fbdev doesn't
On Gwe, 2004-09-10 at 19:19, Philipp Klaus Krause wrote:
What became of the proposal of making fb a DRM client
that I saw on dri-devel some time ago?
It sounded like a good idea to me.
That falls out from just about all sane and non-sane ways of
tackling the problem. Its essentially a freebie
On Iau, 2004-09-09 at 00:45, Ian Romanick wrote:
So, what happens in x86-64 where sizeof(unsigned long) is 4 bytes for
IA-32 apps and 8 bytes for x86-64 apps? I guess since it's a parameter
to the ioctl (rather than embedded in a structure) it should be okay,
but I just want to be sure...
On Mer, 2004-09-08 at 14:40, Ville Syrjl wrote:
Like Jon said the hardware can do it but the XFree86 driver doesn't allow
it. AFAIK it doesn't even allow XAA acceleration on the secondary head.
I can run multiple 3D apps simultaneosly on both heads of my G400 with
DirectFB. But currently
On Maw, 2004-09-07 at 10:07, Patrick McFarland wrote:
Also, what happens to r200 users who happen to use Debian? Using dri
cvs snapshots
If Debian is currently shipping a buggy driver then Debian needs to ship
a working driver. Same as anyone else. You'll also need the newest
dri driver for
On Llu, 2004-09-06 at 21:58, Hamie wrote:
The fs - SCSI interface is a logical one.
We just have to make the fb and DRI to hardware one logical.
Unless you can have fb sitting on top of DRM of course... (I discount
DRM on-top of fb, because of the D == Direct... No other reason :)...
Does
On Llu, 2004-09-06 at 21:19, Philipp Klaus Krause wrote:
'Did some more testing and found bugs.
Here is the corrected patch.
Not having looked at this before - is there a reason for DRI_CONF_DESC
not using standard internationalisation functions.
On Llu, 2004-09-06 at 22:50, Felix Khling wrote:
We want the description strings in all available languages to be
compiled into the 3D drivers. All these macros result in a small
XML-document which is looked up via dlopen/dlsym by the configuration
tool (or xdriinfo as a helper for script
On Sad, 2004-09-04 at 19:03, Jon Smirl wrote:
This does add some work to the BSD developers but it would make all of
the new code that doesn't copy preexisting GPL code fair game. I have
no problem marking any new code I write as being BSD licensed, I just
don't want to rewrite 80,000 lines of
On Sul, 2004-09-05 at 16:05, Jon Smirl wrote:
If DRI stays the way it is currently licensed no problems arise anyway
(beyond proprietary people reusing DRI code, which given the license is
presumably the intent)
If I copy GPL pieces of fbdev in to the DRM drivers it will pollute
the BSD
On Sul, 2004-09-05 at 16:33, Jon Smirl wrote:
Then how am I going to merge fbdev and DRM so that we don't have two
drivers fighting over the same hardware?
Everyone else in the discussions but you seemed to have no plans to
merge them, yet you keep going back to that plan and ignoring the
On Sul, 2004-09-05 at 15:44, Alan Cox wrote:
On Sul, 2004-09-05 at 16:33, Jon Smirl wrote:
Then how am I going to merge fbdev and DRM so that we don't have two
drivers fighting over the same hardware?
Everyone else in the discussions but you seemed to have no plans to
merge them, yet you
On Sul, 2004-09-05 at 17:05, Jon Smirl wrote:
They have to be merged. Cards with two heads need the mode set on each
head. fbdev only sets the mode on one head. If I teach fbdev how to
set the mode of the other head fbdev needs to learn about memory
management. The DRM memory management code
The only glue structure you need for most of this is
struct fb_device
{
struct fb_info *fb; /* NULL or frame buffer device */
struct dri_whatever *dri; /* As yet not nicely extracted DRI
object */
atomic_t refcnt;
void
On Sul, 2004-09-05 at 22:12, Jon Smirl wrote:
Sure you can use this to get around both fbdev and DRM trying to claim
the resource. But it doesn't help at all to fix the problem that fbdev
and DRM are programming the radeon chip in conflicting ways.
Once you have the common structure the rest
On Sul, 2004-09-05 at 23:11, Jon Smirl wrote:
What is the advantage to continuing a development model where two
groups of programmers work independently, with little coordination on
two separate code bases trying to simultaneously control the same
piece of hardware? This is a continuous source
On Sad, 2004-09-04 at 13:04, Dave Airlie wrote:
I've got nothing to do with Tungsten whatsoever, I've never met any of the
other major DRI developers, my worries here is this is turning into a
company issue, people keep mentioning Fedora this and that, Fedora is one
distro, I happen to use it,
On Gwe, 2004-09-03 at 09:00, Rogelio Serrano wrote:
Is the VIA Unichrome the most open 3D chipset available?
VIA Unichrome graphic engine docs are NDA although some developers have
them. 3DFX Voodoo3 is probably the most open, then there are a couple we
have docs for and no drivers.
On Iau, 2004-09-02 at 15:04, Thomas Hellstrm wrote:
Could this be acceptable security-wise?
I'd add an upper limit to the kmalloc buffer size of say 32K
(realistically thats as big as will be reliable anyway). Otherwise looks
ok. It does do the offset maths twice once without need and loads
On Llu, 2004-08-23 at 18:46, Erdi Chen wrote:
I plan to clean up the unichrome 2D driver with respect to this, but I'm
not sure when this will happen.
DRI code also uses the 2D engine. How does that work?
The DRI layer wraps enough of the X driver code that the X server is
part of the DRI
On Sul, 2004-08-22 at 02:51, Jon Smirl wrote:
Michel pointed out that all IOCTL calls hold the big kernel lock.
Releasing this lock is sure to case problems since the DRM code is not
designed to be reentrant.
That lock is already released whenever the code sleeps (eg page faults)
so if its
On Sul, 2004-08-22 at 07:16, John Lightsey wrote:
I shut off most of the services on the machine. rcconf shows klogd, makedev,
and sysklogd as the only services active at boot. The kernel used was
2.6.7-1-k7 from Debian.
Which DRI kernel modules - the CVS tree provided ones or the 2.6.7
On Sul, 2004-08-22 at 13:11, Dave Airlie wrote:
there should be no regression between them, I'd expect the currrnt CVS
ones might in theory be slower than 2.6.7 but I haven't seen any
regressions on the radeon modules while I've been doing the function table
work, 2.6.7 is pretty close to CVS
On Sul, 2004-08-22 at 21:51, John Lightsey wrote:
So... A Radeon DDR 32MB running DRI seems to be faster than a TNT2 32MB.
Matrox G400 seems to be faster on everything other than Unreal Tournament.
I'll send a link to the graphs on Monday.
Maybe I should get the Voodoo2 DRI written. The
On Mer, 2004-08-18 at 12:32, Keith Whitwell wrote:
Once again, I predict the gamma driver which reportedly doesn't work and
doesn't have any users will prove to be the stumbling block...
I would suggest the gamma driver is retired. And I think I say that as
about the only Linux user other than
On Llu, 2004-08-16 at 08:11, Arjan van de Ven wrote:
I would strongly urge you to no longer update DRM in 2.4 in significant
ways. 2.4 is the release for doing strict maintenance; people who want
to run newer X will generally run 2.6 kernels as well anyway.
Then 2.4 users can't use the new
On Iau, 2004-08-12 at 21:27, Erdi Chen wrote:
I have some working test code that implements AGP ring buffers (the
current DRI code waits for engine idle and ping pongs between two big
buffers). For multiple clients, each client would have its private
buffer allocate it system memory. The
On Mer, 2004-08-11 at 02:00, Mike Mestnik wrote:
--- Dave Airlie [EMAIL PROTECTED] wrote:
Can the VIA DRI stuff get pushed through to the kernel with the S3
stuff please, even if we mark VIA as experimental
the DRM stuff? We need to mark as insecure, I really don't want anything
On Mer, 2004-08-11 at 01:29, Dave Airlie wrote:
Can the VIA DRI stuff get pushed through to the kernel with the S3
stuff please, even if we mark VIA as experimental
the DRM stuff? We need to mark as insecure, I really don't want anything
that the authors consider insecure to go anywhere
On Mer, 2004-08-11 at 02:20, Dave Airlie wrote:
the VIA/mach64/savage DRM when setup by the current DDXs all allow evil
things from my current understanding, that is why they're DDXs haven't got
the DRI support turned on by default in Xorg, so those DRMs are not to be
built into a release, I
On Mer, 2004-08-11 at 13:53, Thomas Hellstrm wrote:
When I did some cleaning up of the via drm code I noticed that the memory
manager seems identical to the SiS one, so if there is a problem with
that, then there is a problem with the via driver.
Yeah I know about one.
Also the unichrome 2d
On Mer, 2004-08-11 at 21:59, Dave Airlie wrote:
From Erdi Chen: erdi the Via unichrome chip supports system memory to
framebuffer DMA bitblt, currently the DRI driver maps the IO registers to
user space, that maybe a problem
Now that statement is enough for me to block it going anywhere
On Maw, 2004-08-10 at 06:23, Kevin E Martin wrote:
On today's release wranglers call, someone asked if there were any new
fixes from the DRI or Mesa projects that should be included in the next
X.Org release. If there are any, could you please let us know? Thanks!
Can the VIA DRI stuff get
On Gwe, 2004-08-06 at 18:16, Jon Smirl wrote:
fbdev is in exactly this model and it isn't causing anyone problems.
The simple rule is that if you want to upgrade fbdev past the current
version you have to do it in entirety. You do that for fbdev but
pulling bk://fbdev.bkbits.net/. But Joe user
On Sad, 2004-08-07 at 17:37, Kronos wrote:
You can check and see if the ROM is really big and use vmalloc, if not
then you use kmalloc (if I remember correctly my radeon has a 4KB ROM -
vmalloc would be overkill).
You can also read it out to userspace in a loop in chunks thus needing
only a
On Sad, 2004-08-07 at 18:40, Jon Smirl wrote:
We have to copy the whole thing when the driver tells us to. After we
copy the ROM the hardware is going to use the address decoder for
something else. There is no safe way to get back to the ROM again other
than to unload the device driver.
Good
On Llu, 2004-08-02 at 19:57, Dave Jones wrote:
The problem is that each driver has different needs based on hardware
functionality.
How does this differ from any other subsystem that supports
cards with features that may not be present in another model ?
Other subsystems have dealt
On Llu, 2004-08-02 at 22:09, Dave Jones wrote:
Whip me, beat me, make me clean up drivers/char/drm
8-)
Im sure that can be arranged by someone.
Another possibility of course is that the BSD Linux kernel side bits
go their seperate ways. How active is the kernel side of the BSD world ?
On Iau, 2004-07-29 at 08:38, Kenan Esau wrote:
My testing has been limited to the older DRI with Arjan's patches to fix
user/kernel confusion and radeon cards, but that much does work.
Did you also use an older Matrox card G200/G400, ... ??
I assume the error is located somewhere in the
On Iau, 2004-07-29 at 01:27, Ian Romanick wrote:
So, I'm going to rework the interface a little bit so that the allocator
can look at all the require allocations at once. It will place them in
memory using some sort of path finding algorithm (probably A*). That
seems like a reasonably
On Mer, 2004-07-28 at 07:57, Ian Romanick wrote:
Kenan Esau wrote:
I am sorry if I am asking FAQs. But I just want to know if someone is
working on this and if I can help debugging this problem.
If you think there is no problem this would be also interesting for me.
I don't know of
On Mer, 2004-07-28 at 19:53, Jon Smirl wrote:
First a basic definition. There are two consoles, the kernel one
(printk, kdbg, OOPs, etc) and user one (normal console logins). There
is no requirement that these consoles be handled with the same code
even though they are today.
Not sure that
On Mer, 2004-07-28 at 22:31, Kronos wrote:
There was a thread on acpi-devel about POSTing VGA ROM after resume:
http://marc.theaimsgroup.com/?l=acpi4linuxm=109023076427394w=2
The code does a real mode switch in kernel and execute the ROM. Ok, doing
that in userspace is more elegant, but
On Llu, 2004-07-26 at 22:09, Jon Smirl wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Additionally, by making this step root-only, the X server is
effectively
required to perform this task, meaning that the client must be
'blessed' by
the X server's security mechanisms, whatever
I've posted a tarball of the current state of play on
ftp://people.redhat.com/pub/alan/XFree86/SiS/
[I need to rename the directory some day]
In addition you need to add the sis6326 PCI id to the sis dri kernel
module table (dri_ids.h if I remember rightly).
Currently it draws triangles with
On Iau, 2004-07-15 at 00:19, Felix Khling wrote:
It's not exactly a known problem. I havn't had problems with scissors
yet, probably because it's not widely used in games and other stuff I
tested. I suspect that scissors interact badly with the window cliprect.
It's still a big mess in the
On Gwe, 2004-07-02 at 13:32, Rafael de Pelegrini Soares wrote:
Hi all,
I'm looking for DRI support for a Sis6326 but could not found nothing
working on XFree4.
So, I would like o port the UthaGLX-XFree3 driver to DRI.
Somebody is working on Sis6326 dirver or can give me some guide lines?
On Gwe, 2004-07-02 at 17:59, Rafael de Pelegrini Soares wrote:
What is missing is a matter of the porting status or needs development
specific for DRI?
If it is a matter of porting I could help, otherwise I'm afraid that I
have not knowledge enough.
The 2D changes will need re-merging
On Iau, 2004-07-01 at 13:17, Dieter Ntzel wrote:
First, please STOP HTML mails. - Without there is a big chance to go directly
into /dev/null...;-)
If you're interested I have a 'late' copy of the tdfx SLI tree.
I've been looking at SLI on the Voodoo2 and with X its really hard
since it
On Mer, 2004-06-30 at 13:45, [EMAIL PROTECTED] wrote:
I am developing the DRI driver for s3 latest product DeltaChrome.
XFree86 version is 4.3.0,and gcc is the default in redhat9.0,
and the output of gcc -v is:
cc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Furthermore,if I enable -O2
On Llu, 2004-06-28 at 16:17, Jon Smirl wrote:
Nvidia has started talking about this:
http://www.hardwareanalysis.com/content/article/1728/
History recycled. Take a look at any Oxygen GMX2000 some day, that takes
the same approach on card but in silicon using a Glint Gamma to
partition work
Where DRI is not supported it's not used, why should any other driver be
forced to work every where?
All the current drivers barring some OS specific things like Linux frame
buffer driver work when DRI isnt available on that platform and fall
gracefully back to 2D with software 3D, including
On Sad, 2004-06-12 at 00:53, Ian Romanick wrote:
I think I would actually prefer it if the 3D were named unichrome_dri.so
and the DDX were changed. The reason being that there will likely be
future via chipsets that may share the 2D driver but not the 3D. The
current situation of
On Sul, 2004-06-13 at 22:58, Mike Mestnik wrote:
The DRM is a kernel driver that allowes the user-apps to use a 3D cards
API. Fbdev is smaller then the DRM and will be asimulated and it's
functions emulated or replaced.
On Linux and FreeBSD only, and there isnt yet a consensus on the
On Sul, 2004-06-13 at 20:20, Torgeir Veimo wrote:
At least he is trying. There's no need for bashing people who try to
implement new ideas.
I'm not. I'd rather he listened to new ideas and took feedback but that
is his business and the community has ways of dealing with that problem
that work
On Sul, 2004-06-13 at 20:35, Jon Smirl wrote:
The work that would be wasted is extending the XAA 2D drivers to use the 3D
hardware to accelerate render.
Lots of hardware can do render without 3D operations. Even my
TV capture/playback card has blit-with-alpha on it. Extending existing
XAA
On Sul, 2004-06-13 at 03:07, Jon Smirl wrote:
Why not help getting mesa-solo working so that we can move to X on top of
OpenGL?
For one, in the two years that is going to take to bear fruit, we need a
working X server. Two because mesa-solo isnt supported on most of
the Xorg platforms.
Alan
On Sul, 2004-06-13 at 20:47, Matt Sealey wrote:
Linux basically falls behind on two simple fronts at the moment:
it has no simple 2D or 3D framework capable of much more than
I deal with embedded Linux people on a daily basis. I think they would
disagree. For 2D it has several in heavy use
On Sul, 2004-06-13 at 16:34, Jon Smirl wrote:
The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't
get to work on a response. Getting mesa-solo running everywhere wouldn't take
two years if more people would pitch in and quit arguing. Right now we should
have a
On Iau, 2004-06-10 at 10:46, Dave Airlie wrote:
okay I've checked this into the drm bk tree and DRM CVS, I've no way to
test it apart from visual inspection and it compiles, I've asked Linus to
sync the drm tree again, I probably need to add some __user annotations in
a few places..
I've got
On Iau, 2004-06-10 at 20:50, Alan Hourihane wrote:
O.k. I've popped the 2D ddx into XFree86's CVS, followed up by a merge
of a snapshot of Mesa 6.1 from back in March time. Along with that, I've
also merged in the latest DRM kernel modules in XFree86's tree as well.
Is the 915 driver code
On Sul, 2004-06-06 at 05:34, Alex Deucher wrote:
at http://www.cirrus.com/ftp/pub/gd5465trm.pdf. Since it used to be
publicly available, perhaps you could just ask the nice folks at
Cirrus
Logic for it?
You might also still be able to get it on the internet archive.
Cirrus pulled
On Gwe, 2004-06-04 at 01:10, Dave Airlie wrote:
Do you know if the VIA DRM is considered secure with respect to DMA
buffers and the like? I've been thinking of pushing it to Linus,
It certainly needs further review. As I understand it the VIA one should
be ok, but the S3 one that went over the
be to just grab unichrome's tree or
grab the source Alan Cox fixed up. On the other hand, I'm not really
an expert on VIA development, so I may be wrong.
The DDX in Xorg should work fine with the DRI modules assuming they
applied the patches. If not then Mike Harris has the right driver
bits
On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
There are two types of VTs - text and graphical. It is only practical to have a
single graphical VT because of the complexity of state swapping a graphical VT
at VT swap.
Could have fooled me. I can switch between multiple DRI using X servers
and
On Mer, 2004-05-19 at 20:49, Jon Smirl wrote:
A rep from the SELinux group was at the Xdev conference. They are starting a
project to verify X server.
Verifying the X server isnt practical. Its large and its reliant on
hardware behaviour for hardware where nobody has documentation and where
the
On Iau, 2004-05-20 at 01:55, Jon Smirl wrote:
It's not going to allow multiple login prompts on different VTs on the same
head.
In which case its completely useless. You might want to get away from a
kernel virtualisation of video services but you just can't do it. You
can pull a *lot* of the
101 - 200 of 406 matches
Mail list logo
