Re: [PATCH 2.6.9-rc2 3/33] char/drm_os_linux: replace direct assignment with set_current_state()
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 careful. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: add missing pci_enable_device()
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 device. If you are calling pci_disable_device at all in the fb driver or DRI driver it is wrong, always wrong, always will be wrong for the main head. The video device is almost unique in that when you unload all 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) Alan --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: add missing pci_enable_device()
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 we can test it? I don't know which DRM supporting cards are affected and which platforms will turn off enough for disable_device to break. I guess vgacon will need a place in the vga class driver stuff that way the ISA console space would always be owned ? --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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. Insert card pc layer calls hotplug hotplug loads vga driver pci layer calls vga driver vga driver generates hotplug event hotplug loads stuff (user policy) vga driver calls hotplugged drivers I guess you need to build something into the VGA driver that gets the PCI ID tables out of the various fbdev/DRM drivers and combine them into a single table visible to hotplug. Then let the VGA driver take the hotplug event. The VGA driver can then search it's table and figure out which driver to initialize. Thats what it does. The vga_device_register functions take a vga_driver object which is a PCI driver lookalike with an extra field of type so you can load DRM's, FB's etc What if I have two identical PCI video cards. Don't we need an initialization file to say load DRM on the one in slot 1 and fbdev on the one in slot 2? Possibly, thats for hotplug user space policy. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM: add missing pci_enable_device()
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 card when DRI unloads is unbelievably *wrong*. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 via the X tree and distributions
start relasing kernels with it merged into it
Unlikely. Its rapidly unmaintainable because the core kernel changes
will obsolete it (see for example KGI).
I think yourself and Linus's ideas for a locking scheme look good, I also
know they won't please Jon too much as he can see where the potential
ineffecienes with saving/restore card state on driver swap are, especailly
on running fbcon and X on a dual-head card with different users.
Well this is what I came up with so far. It creates a vga class so you
can bind the drivers to functions of the card (and we can add/remove
functions later as appropriate), tells functions about each other and
now implements Linux lock proposal as I understood it.
Alan
/*
* drivers/video/vga-driver.c
*
*/
#include linux/pci.h
#include linux/module.h
#include linux/init.h
#include linux/device.h
#include asm/semaphore.h
#include vga_class.h
/*
* Registration of video drivers and handling of hot-pluggable devices.
*/
static LIST_HEAD(vga_devices); /* No I don't know why its not DECLARE_LIST_HEAD either */
/**
* vga_match_one_device - Tell if a PCI device structure has a matching
*PCI device id structure
* @id: single PCI device id structure to match
* @dev: the PCI device structure to match against
*
* Returns the matching vga_device_id structure or %NULL if there is no match.
*/
static inline const struct vga_device_id *
vga_match_one_device(const struct vga_device_id *id, const struct pci_dev *dev)
{
if ((id-vendor == PCI_ANY_ID || id-vendor == dev-vendor)
(id-device == PCI_ANY_ID || id-device == dev-device)
(id-subvendor == PCI_ANY_ID || id-subvendor == dev-subsystem_vendor)
(id-subdevice == PCI_ANY_ID || id-subdevice == dev-subsystem_device)
!((id-class ^ dev-class) id-class_mask))
return id;
return NULL;
}
/**
* vga_match_device - Tell if a VGA device structure has a matching
*PCI device id structure
* @ids: array of PCI device id structures to search in
* @dev: the PCI device structure to match against
*
* Used by a driver to check whether a PCI device present in the
* system is in its list of supported devices.Returns the matching
* vga_device_id structure or %NULL if there is no match.
*/
static const struct vga_device_id *
vga_match_device(const struct vga_device_id *ids, const struct vga_dev *vdev)
{
struct pci_dev *pdev = vdev-pci_dev;
while (ids-vendor || ids-subvendor || ids-class_mask) {
if (vga_match_one_device(ids, pdev) ids-unit == vdev-unit)
return ids;
ids++;
}
return NULL;
}
static void vga_device_notify_install(struct vga_dev *vdev, int type)
{
int i;
for(i = TYPE_MEM; i TYPE_LAST; i++) {
struct vga_dev *v = vdev-shared-device[i];
if(v != NULL v-driver i != type)
v-driver-notify_attach(v, type);
}
}
static void vga_device_notify_remove(struct vga_dev *vdev, int type)
{
int i;
for(i = TYPE_MEM; i TYPE_LAST; i++) {
struct vga_dev *v = vdev-shared-device[i];
if(v != NULL v-driver i != type)
v-driver-notify_detach(v, type);
}
}
/**
* vga_device_probe_static()
*
* returns 0 and sets vdev-driver when drv claims vdev, else error.
*/
static int
vga_device_probe_static(struct vga_driver *vdrv, struct vga_dev *vdev)
{
int error = -ENODEV;
const struct vga_device_id *id;
if (!vdrv-id_table)
return error;
id = vga_match_device(vdrv-id_table, vdev);
if (id)
error = vdrv-probe(vdev, id);
if (error = 0) {
vdev-driver = vdrv;
down(vdev-shared-shared_sem);
vdev-shared-users++;
vga_device_notify_install(vdev, vdev-unit);
up(vdev-shared-shared_sem);
error = 0;
}
return error;
}
/**
* __vga_device_probe()
*
* returns 0 on success, else error.
* side-effect: vdev-driver is set to vdrv when drv claims vdev.
*/
static int
__vga_device_probe(struct vga_driver *vdrv, struct vga_dev *vdev)
{
int error = 0;
if (!vdev-driver vdrv-probe) {
error = vga_device_probe_static(vdrv, vdev);
}
return error;
}
static int vga_device_probe(struct device *dev)
{
int error = 0;
struct vga_driver *drv;
struct vga_dev *vdev;
drv = to_vga_driver(dev-driver);
vdev = to_vga_dev(dev);
vga_dev_get(vdev);
error = __vga_device_probe(drv, vdev);
if (error)
vga_dev_put(vdev);
return error;
}
static int vga_device_remove(struct device *dev)
{
struct vga_dev *vdev = to_vga_dev(dev);
struct vga_driver *vdrv = vdev-driver;
down(vdev-shared-shared_sem);
vdev-shared-users--;
if (vdrv) {
vga_device_notify_remove(vdev, vdev-unit);
if (vdrv-remove)
vdrv-remove(vdev, vdev-shared-count);
vdev-driver = NULL;
}
vdev-shared-device[vdev-unit] = NULL;
Re: radeon-pre-2
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 Xserver+framebuffer combinations Jon's proposal wins. 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. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 objects in the code I posted get passed vga_dev objects. You can put what you like in those. I guessed at memory manager dri and framebuffer0 being the ones to create for now but we can invent anything thats more appropriate. It also needs to track pci_enable_device() so that if one driver unloads it won't turn the device off for the other driver. The -remove function is passed the number of remaining clients for exactly this reason. We could move the resource grabbing up the tree. IRQ handling is rather harder. Quiescing and handing back the IRQ on lock loss is ugly so I want to think about it - it works but its not nice. Should pci_enable and friends be done by the vga class driver- it can do this and it would have to do it if it did the hotplug ? VGA routing needs to be supported. I attached the code I was writing for that. I was in the middle of writing it so it doesn't compile. This code should be integrated into the VGA driver. Agreed. It needs to integrate into VGAcon. VGAcon should require the vga device before loading. The resource reservation code in VGAcon needs to be moved to the VGA driver. If you use a command to switch the active VGA device, VGAcon needs to reset itself for the new device. I saw vgacon as being a client of the vga class driver like the various fb drivers would be. VGA driver needs to generate hotplug events for the VGA device that indicate if they are primary or secondary. If they are secondary there needs to be a user space reset program that uses the new ROM hooks to reset the card. The VGA driver at the moment doesn't really know about legacy vga space. That was something I wanted to touch last of all because it is foul. It can do this and as you say its the perfect person to issue the hotplug notifications. It also needs to do it for vesafb so if it is handed an ISA hole it can work out the right PCI device. It should support more than two drivers, I forgot to check, does it already? As many as you want. Just change the array size or the number registered. One neat trick we can support is adding extra devices when necessary - thus if the boot code in user space boots a card and decides its multihead we'd want to add extra heads. fbdev takes a snapshot of the video registers when it loads. When you unload it it writes those registers back. That doesn't work if you load from an xterm and rmmod it from the command line. It snapshots the card in graphics mode and then restores it in an environment expecting text mode. Big lock issue. You get told if someone else ate your environment. Being more polite about that would help performance a ton. You know who had the lock before and who has it now - so we can be intelligent about -release cleanup I hope. (eg FB0 finds FB1 had it last it might do a minimal restore) Something needs to be done for DMA processing. What if I get an interrupt that the DMA queue has been completed but we've switched to a driver that doesn't understand DMA? I guess the only safe thing to do is make sure all DMA queue are finished before releasing control. The -remove path takes the lock (so calls -release) and then drops it with no callback needed so providing the hand over code is robust this will come for free. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 pieces of code in the framebuffer - one that can program the card in the absence of DRM driver and one that uses CP when it is present ? We could do, or the DRM driver could provide DMA methods for the framebuffer driver to use. I mean it might be that we should always be using DMA methods in all the drivers for radeon all the time anyway ? The fb driver gets told when DRI comes and goes which means the two can choose to co-operate if they wish. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 nice and it should integrate really easily as well as remove most of the PCI layer patching it now does. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 stable if you used the external AGP rather than fglrx's built in AGP driver? Who knows, ATI have the source, ask them 8) My code ends up looking like lock if(someone_else_used_it) restore_my_state() blah unlock Ah... Now I understand what you've been talking about as well... The only caveat is whether you can always restore your own state from the state the other person put it into. Do any cards exist where you could perhaps still lock the card up because you didn't know the current state of the card? There are lots of cards where you might need more than the basic example. You need to know your own state clearly, you often can't retrieve that from the card. You may also need to know the previous user has left it in a sane state. That might lead you to say lock oldowner-release() blah unlock (release_func) so that the previous caller is told it is losing the lock and can for example wait for its commands to complete. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: locate of drm.h
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. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New version of dyn-minor.patch
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 anyway. The DRM(probe) macro is there for the same reason. Without the macro if you link two DRM drivers into the kernel you'll get symbol Then I don't see why you've suddenely made it required undoing cleanup that had been done ? Why does the minors patch suddenely introduce this specific requirement ? Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 (at least), an unaccelerated 2D path via programmed registers, and an accelerated path via some DMA mechanism, this isn't a 2d/3d split, you have to use the DMA mechanism for doing some 2d acceleration and you have to use it for all 3d acceleration normally, And a CD ROM is a round thing with removable optical media, while a hard disk has a different command set and is magnetic. They are juat as different. Its simple a matter of correct architecture. Lots of X DDX drivers use the accelerator for 2d stuff, some fbs use it for accelerating scrolling, the DRM uses it, this is wrong wrong wrong wrong...X/DRM at least lock each other out, but the fb just tramps in wearing its size nines.. so in summary the 2D/3D split exists in peoples minds (graphics cards designers excepted...) Thats a different issue. IDE has to stop the CD and disk drivers from stomping on each other over a shared bus. This is the problem of them knowing each other exist and interacting. This is the point you need to be able to find DRI from FB and vice versa. The point they need to know about each other being loaded. Multiple registrations on the same object is exactly what the class code in the kernel is for. You end up with a VGA class driver that knows all the video devices. That has the usual match/install functions to allow the frame buffer to attach, but can also have other sets for attaching different client classes. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 sets video modes - i.e. messes with PLL. The problem is that there are configurations where messing with PLL while a DMA trasfer is active will lock up PCI (or AGP) bus hard. Yes its a co-ordination issue. If the IDE disk writes to the bus the same moment as the IDE CD shit also happens. For example, a video decoder can be clocked off pixel clock for video pass through mode. If we trasfer video data to main RAM at the same time and FB gets a command instructing it to change resolution there would be a hard lockup. Gosh, just like if the IDE disk driver changes the bus clocking during an IDE CD transfer. You need co-ordination not some horrible glue it all together and pray hack. Thats always going to be true, and since you can do it without glueing it all together you might get somewhere by keeping them apart, otherwise I see no future. Most DRI users don't want FB, most FB users don't care about DRI or want to control the DRI from the fb side. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 about things they don't grasp. You've almost
got the point by now at least.
The IDE CD and IDE disk drivers do both write to registers on the IDE
controller directly - often the same registers. The reason it doesn't
end up in a nasty heap is because the core IDE code does co-ordination.
Two drivers, independant drivers, an access protocol an the ability for
some entity to co-ordinate them and lo - it all works.
a graphics card is a device, singular one device, it requires one
device driver,
That appears to be the pet religion but repeating bullshit doesn't make
it true.
I can't write a user space IDE driver and still expect the kernel one to
be happy, I can't write a second IDE driver for a chipset for formatting
disks and expect the normal kernel driver to stay working with it, why do
people think graphics driver are meant to be different..
Because they are not different, and you can write such a formatting
driver providing it follows the IDE access protocols in the core code.
You won't have to modify existing IDE drivers either. It works because
the co-ordination layer is there.
Alan, I agree with how you want to proceed with this, and keep things
stable, but anything short of a single card-specific driver looking after
the registers and DMA queueing and locking is going to have deficiencies
and the DRM has a better basis than the fb drivers,
I want to own it, mine mine. Pathetic really isn't it. The FB writers
I've no doubt think they should own it and their code is better too.
They also support a lot more hardware than you do of course, and on
platforms that DRI doesn't support.
What is actually so hard about driver code that instead looks like
my_fb_attach_notify(struct vga_dev *dev, int type)
{
if(type == TYPE_DRI)
{
me-fb_ops = dri_ops;
my_fb_dri_init(dev);
return 0;
}
if(type == TYPE_OVERLAY dev-rev 0xC4) /* Errata */
return -EINVAL; /* Refuse overlays in fb mode */
}
or
down(dev-lock);
vga_quiesce_all_drivers(dev);
do nasty non parallel stuff
up(dev-lock);
This is essentially what the IDE layer does, although its closer to
queue_this_function_and_args_to_list(dev, callback, args);
if(!doing_stuff);
begin_queue_run(dev);
Either model works
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 form .. I much prefer the evolution of these things than complete new solutions... but I also think linking the fb and drm code together will remove alot of the headaches and result in a more maintainable system longterm, even if shortterm there are some ugly hacks.. What I'm trying to end up with is this drv.type = TYPE_FB0;/* Head 0 */ /* Rest much like PCI */ vga_register_driver(drv) drv.type = TYPE_DRI; vga_register_driver(drv) all working like the PCI API, so you get add/remove notifications, you also don't need to modify the video and DRI drivers much. Unlike the pci_register it allows multiple claims for each device (one memory manager, one dri driver, up to four heads for now - multihead needs more pondering perhaps) Each of these gets notified when the others are added/removed and can veto such an add or remove. They can also provide whatever methods it turns out are appropriate to each other for co-ordination. For example I can see the radeon DRM driver providing -queue_commands() -quiesce() to the 2D driver. And the 2D driver providing -define_fb_layout() for DRI to provide to X That way it is only these calls between drivers you and the fb authors have to argue about the functionality and interfaces between. (eg who saves registers, which registers) Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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. The moment you have that it becomes down(dev-foo-pll_lock); Thus at the very least you would want to mandate the availability of mode setting part of FB when DRM is loaded - and they you can just as well link the relevant code together. You are making a generic assumption for a single card specific problem in a specific situation. That leads to bad decisions for embedded. It does argue for mode setting and fb to be separate too. (Remember for most embedded devices mode setting code is trivial) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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, it can trigger fbcon. This in-kernel driver need not know anything about the hardware (unless 2D acceleration is needed). Thats great because one of the things X wants to tell DRI to tell the kernel eventually is by the way the area visible is laid out like this shoudl you want to panic on it. (Jon wants to move the mode setting out of X eventually and that follows the same line of requirement nicely). --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 from the respect of the resources. EVERYBODY else would be a stealth driver. Not just DRM. How do you plan to deal with hot plug. At the point the silly driver (in my case this is the vga class driver) claims the PCI device and propogates things onwards hotplug seems to work. The second fun bit is that Jon is right that in some cases the fb driver for a card may want to use the DRI layer if loaded - but only some and only in a controlled manner. Sometimes the drivers want to co-operate sometimes they just want to avoid beating each other senseless. Now, the reason why these things are _pointers_ to locks rather than locks themselves is that maybe some hardware ends up sharing resources between these things (maybe modeswitch needs the accelerator to How do you deal with making sure the lock doesn't get freed and knowing who needs it still ? I ended up with locks in the shared area itself because I couldn't figure that one out ? - memory allocation. Many of these issues really are generic, and once you have the locking setup done, maybe you can have a generic memory allocation layer for splitting up AGP memory or whatever. See the dma_declare_coherent_memory() interfaces that James Bottomley did for some SCSI devices that have on-board memory that they want to let the kernel allocate as DMA'able. I think allocation is genuinely a hard problem in the 3D card case. Some devices have the most wonderful restrictions on layout that range from the frame buffer is here to I want 2Mb, 1Mb aligned within a 4Mb range and you can free this stuff if you notify me but its not textures. Multihead really makes this interesting and DRI itself doesn't really address this problem either. Linus let me run what I have now past you for comment (the code isnt working yet since I've been having a fight with the class code) The vga_class module registers itself as the owner of every VGA class device on the PCI bus. The PCI layer duely gives it all the video hotplug events. On creation it creates a set of (currently 3) vga bus objects for each card. So if we find say a Voodoo 3, we will create vga bus objects Voodoo 3 memory manager Voodoo 3 DRI Voodoo 3 Frame buffer 0 (for now. Quite possibly mode management is separate, maybe memory manager eventually will or will not be) and stick them onto global and per vga router lists. vga_register_driver works like PCI register driver but also takes a type field and will attach to the appropriate one of the 3 objects, detach on hotplug and all the rest as the base/* code provides. When you attach or detach you get a notifier to the other members that are loaded. Finally there is a shared structure between the different vga bus objects for each video card which allows you to find one function from another (maybe the notifiers should pass these) and also a semaphore. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 ? Jon wants to get mode setting into a seperate piece of functionality - preferably in user space for many cards. I'd dearly love to see hotplug handing all but some emergency pre-computed mode settings. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 you implement it wrongly sure. If you implemented it right then this occurs. User 1 queues 20 ms of 3D commands User 1 is pre-empted User 2 wants the 2D engine User 2 beings wait for 2D User 2 sleeps User 1 wakes User 1 beings wait for 3D but discovers a claim is in progress User 1 sleeps User 2 wakes, runs commands If you have DRI loaded then as you rightly say the obvious desired outcome is that the fb engine either turns acceleration off or switches to using the DRI layer. But this is a pretty obscure case, and one we can't even begin to support yet anyway. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 leave the coprocessor always running and convert everything to use the DMA based commands. On such a card when DRI is available that is probably the right path, especially if it has the can't software touch the frame buffer while the engine runs design flaw. If DRI isn't loaded, or isn't running you can carry on unaccelerated. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 you implement it wrongly sure. If you implemented it right then this occurs. User 1 queues 20 ms of 3D commands User 1 is pre-empted User 2 wants the 2D engine User 2 beings wait for 2D User 2 sleeps User 1 wakes User 1 beings wait for 3D but discovers a claim is in progress User 1 sleeps User 2 wakes, runs commands If you have DRI loaded then as you rightly say the obvious desired outcome is that the fb engine either turns acceleration off or switches to using the DRI layer. But this is a pretty obscure case, and one we can't even begin to support yet anyway. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely). Thats actually the easy case. We don't care if it takes another 30th of a second to flip console. The hard one Jon was trying to point out is a dual head card. Head 0 has someone running bzflag, head 1 has someone editing an open office document. You have one accelerator set for both heads. At that point you do care about the switch over, but the drivers can co-operate for it. So it would always work, but it would work better with friendly drivers when there is a need to do so. Currently this fails to work... Presumably because the fb DRI code (fglrx here BTW) don't talk to each other so the display gets garbled if you're lucky... Lockup if you're not. fglrx stomps blindly on everything including your AGP. Not much we can do about it. although Alan's probably works for DRI fb on separate heads, how does it guarantee that the chipset is all setup the same way for each process on different heads... (When they have to share some of the hardware). Or is that necessary? You assume someone else crapped on the hardware. That is how DRI works for example. You have multiple rendering clients each of which when it takes the lock finds out if it was the last user (thats one thing Linus sketch lacked but is easy to add). My code ends up looking like lock if(someone_else_used_it) restore_my_state() blah unlock --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 write the code needed to implement the major points of the plan. I'll try and debug the vga generic (Linus stupid driver as he calls it). That'll provide the framework to plug the other bits in. That needs doing anyway to get hotplugging and all the other sane stuff right (oh and probably sysfs but someone else can do that). I was using much simpler lock ideas than Linus but I'll have a poke at that too, something more like a dri lock that knows who had it last. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 BSD folks don't want GPL frame buffer code in there kernel, nobody needs a single nasty splat where DRI and fbdev got hammered into one block of code by someone with a glue gun. Plan as orginally posted to lkml: http://lkml.org/lkml/2004/8/2/111 None of which is about nailing all the code together. You just don't need to do that kind of stuff, and it'll make it much harder to maintain. Now, think about what happens if you register a pci handler for everything which is Video class (or VIDEO/VGA). Your one mini module now claims every video object in the kernel with a couple of exceptions you can hand list. vga_class.c now owns all the video devices. It can keep a global list and a sorted by vga router list as well as letting frame buffer drivers and other code add heads of a device lists. Add register/unregister functions in the same format to allow DRI and FB (and any future layers) to find cards and you don't need to glue stuff together at all. You can load dri, you can load fb drivers, you can load both. You also require minimal kernel changes to the drivers. That is what I keep telling you, that is what I've been fiddling with but keep getting distracted from by immediate locking and other kernel catastrophes. === If the kernel community is going to reject this plan please let me know now so that I won't waste a year of my life writing the code for it. If Linux wants to stay with a 1980's desktop that's fine; at least Microsoft and Apple are innovating. I see you've been taking lessons from Hans Reiser. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 to where we want to be without breaking anything major and without leaving everyone else behind or going a different way. Thats happened at least twice before in the console world because people didn't get it. Kgi is one case, ruby is another. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 hardware for video and not for anything else.. (remembering graphics cards are not-multifunction cards - like Christoph used as an example before - 2d/3d are not separate functions...)... We've addressed this before. Zillions of drivers provide multiple functions to multiple higher level subsystems. They don't all have to be compiled together to make it work. 2D and 3D _are_ to most intents and purposes different functions. They are as different as IDE CD and IDE disk if not more so. something worthy of multiple PhDs (maybe I'll go back to college), Ians work is going to exist mainly in userspace using the DRM for paging things and locking, I think the only way we can really do this is with a simple fb memory manager in the kernel that the userspace one overrides and then tells the fb drivers the new settings - and the fb drivers use those settings until told otherwise.. The memory manager is a later problem. Yes you need minimal memory management in kernel but you have to put the pieces together in a sane way *first*. Having a vga class device is easy. It fixes up your multiple pci device registration problem, it allows DRI/fbdev co-existance, it fixes hotplugging. It's about using the kernel tools we already have and implementing it the way the kernel wants to think. If you fight the kernel you get a mess, if you move with it then it ends up where you want it. Kind of like Aikido source management. The basics I have provide (well they crash but they will provide) the equivalent of pci_register_* for video and DRI modules. Notifiers for use between the two and an ability to find one from the other. Once you have that then you can begin plugging in crap like memory managers for those cases you need it kernel side. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 video devices its simply a matter of taking the mmio address and seeing who owns it. That gives you the PCI device so you now know what the VESA console is Linux pci_device terms. At that point VESA is attachable to the PCI device and so it can veto DRI attaches. I've not addressed what occurs if you get an answer in the ISA window because for VESA2 allocations I don't think it can occur. If it does then Jon's code dealing with finding the live VGA route will handle it for most boxes. (Anyone using VESA video on an IBM summit can fix it themselves). Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: locate of drm.h
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. Please just move the bits you actually need and to the places they belong. The DRM major for example could sensibly be moved to linux/major.h. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New version of dyn-minor.patch
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. + /* use the inter_module_get to check - as if the same module + registers chrdev twice it succeeds */ + global = (drm_global_t *)inter_module_get(drm); inter_module_* is deprecated --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 currently have any memory management. Since the plan is for a mode setting command to take a path unto user space via hotplug it may be possible for all memory management code to exist in user space. The basic point is that the memory management code must be unified. DRI's memory allocator needs are very different to the others. That probably means the kernel API should be very simple and push most of the allocation to user space for rendering work. You want give me 4Mb in kernel , but you don't want allocation for textures in kernel (just profile the via driver). fbdev does btw have memory management, quite a bit of it for some multihead cards. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
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 that exists the instant you can dri_object_of(fb) fb_object_of(dri) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: initmap code
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... Be cautious here - a bus address is 64bits on some builds of x86-32 kernels. Only virtual addresses are 32bit limited. Also don't forget that you run 32bit apps on 64bit platforms. Linux uses __u32/__u64/__s32/__s64 to be specific about such types and to make it easier to build ioctls that don't need magic translation glue --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 DirectFB's multihead capabilities are limited so it only works with a TV as the secondary display. Its a DRI issue not an X one. X has no problem with this but the DRI layer can't deal with the this cliprect this driver, that cliprect a different driver cases. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG] r200 dri driver deadlocks
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 Radeon IGP (most ATI chipset laptops) and the newer R2xx hardware. Alan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 it make sens to have fb ontop of DRM at all? Anyone? In some cases yes. The DRM is happy with the idea of the kernel being a DRM client too. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vertex programs patch for r200 with configuration options -- corrected
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. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vertex programs patch for r200 with configuration options -- corrected
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 based tools). This way information about available options and some human-readable documentation is always in sync with the drivers actually installed on the system. For more background on this design see The internationalisation system supported by all DRI supporting OS's already deals with this itself, and includes things you don't seem to be dealing with like character sets and the fact locales are multi-component (eg en_GB, en_US) and with fallbacks. It seems strange to be reinventing the wheel --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 fbdev code. 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) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 license and turn it into GPL. There is no reason to do that. The fb layer of Linux and BSD is very different and both provide fb drawing functionality. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 other opinions. If you are merging them then something is wrong in the design. The only things they fundamentally share are knowledge of the current display layout, and state management for rendering. As you say if BSD isn't even going to use the code. So why are you trying to make it hard for the BSD side ? They've got a perfectly good frame buffer layer too and not suprisingly it has the same requirements for knowledge. Alan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 keep going back to that plan and ignoring the other opinions. Umm something ate half that paragraph or it got lost between brain and keyboard ;) Everyone else in the discussions didnt think it was neccessary to merge them, yet you keep going back to that plan and ignoring the other opinions. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 is complex and is a big chunk of the driver. I see the entire time at OLS trying to sort this out was a complete waste. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 *private
};
Right now the drvdata for most PCI/AGP frame buffers is set to the
fb_info. If that is set to the shared object then you can attach DRI and
or FB first and they can find and call each others methods.
It might also need a single lock just to avoid DRI deciding to go away
while fb is calling dri and the reverse although I think the refcnt is
easier and cheaper.
With that in place if X tells DRI 640x480 starting here then DRI can
tell fb 640x480 starting here. Similarly fb and dri can find each
other for acceleration and the kernel can become a DRI client for
console acceleration.
Once you have this object you can start attaching memory managers and
mode setup pointers to the shared structure so that they live
independantly.
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 of the problems go away rather nicely over time. What is so awful about merging the code? I'm the one doing the all of the work. I intend to use 95% of the code extracted from fbdev without change. I'm not getting rid of fbdev capability in the merged code, I'm just coordinating use of the hardware. It doesn't solve the problem. That is the fundamental part of it. I can put the code in the same place or in different places, the problem you have to fix is co-ordination, and when you fix that not suprisingly you still don't care where the code lives. Create a top level video device object to hold dri and fb info pointers. End of problem #1. Make that top level video object the one which is handling the pci device irrespective of DRI/fb loading first. You've now solved the load order problem. Make DRI tell fb about display layout in X and provide sync functions. You've now solved the Oops problem. After that you can begin to worry about dual head and memory management which is a *lot* harder than you seem to realise and much of which cannot be done user space side for performance reasons. Alan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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 of problems. Why can't we fix the development model to stop this? I don't see that as much of a problem. The mess arises from some simple lacks in the objects in kernel and the methods required to co-ordinate. Lots of drivers are written by a lot of people in the kernel and they work just fine. The ext3 authors don't spend their lives co-ordinating with SCSI driver authors, they just get the API right. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
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, lots of people I know dont.. it supports DRI on IGP and i915 in Fedora 3 Test only, a DRI snapshot works on FC1 and FC2 as well.. Fedora essentially solves the problem with regularly release cycles and policy. So once we know 2.6.10 or whatever is stable we can push that for FC2 and FC3. We can push Xorg for FC2 because its in the distribution description. Same for Gentoo except they'll probably ship it before Fedora does. Again what about distros that only do security upgrades in stable releases, I would like to give those people a chance to use their graphics cards, and the snapshots are not the only way, For these setups the snapshots work well because you can package up an extra driver in the knowledge that the vendor isnt going to do something Neat. If you want i915 in RHEL3 then that would certainly be the path to take for example. Distribution policies in part dictate the method. It doesn't imply any one distribution policy is somehow right. Alan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: via docs
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. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PATCH: unichrome: Command buffer over PCI ioctl.
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 value without need in the first loop Might be better to do offset (0x7FFU 2) since the maths that end can be done by the compiler. I assume the caller checks we hold the DRM lock ? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unichrome DRM ring buffer patch
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 locking. You get most of that for free. Alan --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
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 broken then its already broken and it doesn't matter. If it isnt broken then its still not broken --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
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 kernel ones ? --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
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 about 5 mths ago... I don't think we have fixed any lockups or anything of that great interest in this time .. At least on the fedora-test list the new Xorg CVS seems to be showing up some i815/830 works with 2.6.8.1 but not 2.6.old kernels. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
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 voodoo2 can wipe the Matrox G400's backside but I'd assumed it was still too slow to be useful --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm round 2...
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 Alan Hourihane who has one 8) --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and 2.4 ...
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 Xorg release fully. That would be rather out of keeping with X policy. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Any patches for X.Org release?
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 private buffer is copied to the ring buffer when the client does a flush. I am hoping to integrate this ring buffer code into the DRM driver sometime soon. Cool stuff - thanks for the status report. Alan --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Any patches for X.Org release?
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 that the authors consider insecure to go anywhere outside the DRM... Just for calarity. The DRM stuff is insecure, it should not go anywhere outside CVS. Details ? --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Any patches for X.Org release?
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 outside the DRM... Who considers it insecure and where is it documented then I'll go and have a look at the issue. I keep hearing indirect references to this but nobody ever answering in detail. BTW: the SiS DRM is also insecure - the memory manager can be used to crash the box. Just feed it random crap in a tight loop and wait. If you use sisfb however it seems ok - that uses a different memory handler. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Any patches for X.Org release?
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 think Eric has a good handle on what is and isn't allowed anyways ... Mach64 isn't entirely secure. Yes we know that the author said so. The via one I'm still trying to track down but its entirely A said B said C thought D considered it insecure. I need the original source of the rumour so I can find out if its true --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Any patches for X.Org release?
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 driver allows XvMC dri clients to map (RW) the framebuffer and the whole register space, and I know that at certain video register write combinations will lock my machine hard. From my point of view, however, this is a deficiency in the unichrome 2d driver rather than in the via drm driver. DRI allows for locking the box. I can lock the radeon, I can lock the matrox. Its supposed to not allow worse than that. The XvMC slice registers for mpeg are all in one location - is that too close to other registers to split up the map ? If not perhaps the slice load should be in the DRI module ? --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Any patches for X.Org release?
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 until I hear different .. Ok so that allows stealing data which is borderline problematic, and I concur on the wrong side. I'll take a look at pushing the render sequences into an ioctl at some point, since it generates long command lists that should be fine. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Any patches for X.Org release?
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 pushed through to the kernel with the S3 stuff please, even if we mark VIA as experimental --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
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 doesn't do that, that is something only developers do. And thats one of the big reasons its such a mess and doesn't work out. Nobody is testing or reviewing it until some huge merge point occurs at which point you run the risk of people saying Actually your design sucks, or in the 2.6 case finding out too late so that there is a patch kit to upgrade your 2.6 to the 2.4 console driver --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] New kernel API for ROMs
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 single 4K page or you could mmap it --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] New kernel API for ROMs
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 point on mmap not working yes. We can still copy it in 4K chunks to userspace though not keep it in kernel. The rom boot stuff in the design is in user space. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM code reorganization
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 with this problem without the need to introduce horrors like the abstractions in DRM. The abstractions are one big mistake IMHO. But in context their origin is easy to understand. The original goal was to support a lot of platforms and to minimise code writing. The Mesa layer uses this kind of templating a lot and for the 3D client side code its a real win. Someone I think took them a stage too far and into a place that it didn't work out. The memory manager is a bit more complex, a lot of drivers do have different needs for memory management and some of it has to be client side. Its also a really really hot path when doing direct render. AFAIK, the only drivers that have any sort of in-kernel memory manager are the radeon (only used by the R200 driver) and i830. ISTR SiS has some memory management code too, though I've not looked too closely at that for a long time. SiS and VIA do as well. Both of them overdo the kernel side work and it hurts performance however. Alan --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM code reorganization
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 ? Eric Anholt works actively on it. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: G400 on AMD64 does not work
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 MGA DRM kernel-module. The 2.6.5 module shipped with the kernel is definitely broken for lots of reasons, on 32bit as well. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Update on video memory manager work
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 good fit. Who thought you'd need AI for a video driver? ;) Cool stuff. The sis6326 needs this ability for a much more primitive reason - because a texture cannot have some levels in framebuffer and some in AGP. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: G400 on AMD64 does not work
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 any DRI developers that have access to AMD64 hardware. 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. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OLS and console rearchitecture
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 was consensus 8) 2) VGA control - there needs to be a device for coordinating this. It would ensure that only a single VGA device gets enabled at a time. It would also adjust PCI bus routing as needed. It needs commands for disabling all VGA devices and then enabling a selected one. This device may need to coordinate with VGA console. You have to use this device even if you aren't using VGA console since it ensures that only a single VGA device gets enabled. Some vendors have multiple vga routers according to bus, unclear how much we care however. the mode registers. Early boot and normal user space will use the same hotplug apps so they need to be as small as possible (good luck IA64 and emu86). IA64 has EFI to get it up initially. 11) OOPs will cause an immediate screen clear and painting of the system console including the OOPs data. It is not needed to change the video mode. Further drawing to the screen will be blocked until SysReq returns to normal operation if possible. No consensus on the screen clear bit - there are actually reasons to argue against it. 16) accelerated, kernel based console drivers are not supported in this model. The only in kernel operations are simple ones like CR/scroll, clear, print text. It is possible to call existing DRM entry points from a kernel thread, but the code needed is complex. Its not unsupported its merely potentially hard because an accelerated driver may well have to be a DRI client. 18) A coordinated system for grouping console devices needs to be designed. This will be bad if each distro does it differently. One proposal is to use udev to create: /console/1/mouse, /console/1/keyboard, /console/1/usb_hub, /console/2/mouse, /console/3/keyboard, /console/4/usb_hub, etc. Another is to use namespace mounts 19) SAK - secure attention key. We forgot to talk about this so we need a design. Falls straight out of having the kernel + helper mode setting --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] OLS and console rearchitecture
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 that code is not a mess (though it's arch dependant). And also some cards do rather deep magic or don't even have a real video ROM but a BIOS hack that goes away. This got discussed - its fun Btw, how do we POST non-x86 (eg. ppc) video boards? I don't think that there's x86 code in their ROM... Same way X does - x86emu 7) Mode setting from normal user space - devices will have a standard IOCTL accepting a mode string like fbdev currently uses. sysfs? I sent a patch a while ago but didn't get much feedback. How do you atomically tie sysfs objects to fbdev and X permissions models ? 14) A new framebuffer memory manager is needed for mesa GL support. Ian is working on it. The memory manager will be part of the support library driver code. sisfb has a memory manager for fb/drm, it may be worth a closer look. Its way too slow and doesn't deal with a lot of things it should, its a problem even on DRI today. Ian has some design for a mostly user space allocator which is critical as DRI can hit 100K allocs/second. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root for DRM context creation
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 they might be. I would like to change this from root+authorized to just authorized in the DRM drivers. In the mesa-solo model context's don't need to pass through the root priv server. You would need to do a full audit of that code path, especially with regards to resource consumption and limits. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
SiS6326 DRI
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 the right x,y but I've not worked out the proper mapping between the z values from Mesa and what the card expects. There is also a locking bug somewhere so run the 2D noaccel. Texture stuff I've yet to even start debugging. Alan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage driver and glScissor
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 driver. If you feel like driver hacking take a look at savagestate.c. That's where the scissors are computed. Given the drivers share the same origin it might be worth noting I've had two bug reports about scissors for the via driver that sound similar. Alan (Still trying to work out how to turn DRI z co-ordinates into sis6326 ones) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Port Sis6326 from UtahGLX
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? Eric Anholt has already done that and I did some more work to get it going - although it doesn't all work yet. By the way, once the driver is ported, Sis6326 can play glquake in a reasonable speed? Providing you are prepared to take a few rendering shortcuts I would think so. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Port Sis6326 from UtahGLX
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 against the current DDX driver and the 3D changes porting to current Mesa. Then the texture and triangle bugs need fixing The current implementation can be found in some sort of distribution or must be compiled from the sources? From sources --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Progress on TDFX driver...
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 news a new cfb type. A good starting point for the DRI Tdfx driver might be to make it work again however. The current one and Glide don't do textures for some people and don't detect the card in some situations either. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI driver broken when I enable gcc -O2 flag
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 flag,the FPS of quake3 can improve about 30frames. I am very curious why gcc can help to improve it so drastically? The basic gcc output is not that heavily optimised. gcc -O2 turns on a lot more optimisation including loop unrolling. It also helps with floating point which matters a lot with Mesa. In some situations I've found gcc -Os (optimise for size) can lead to even faster code. With regard to S J Hill's question - one thing that we've seen with the kernel is that gcc -O2 because it inlines becomes smart enough to eliminate a lot more code or re-order it. That can lead to problems if hardware mappings are not declared volatile. Alan --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple PCI Express cards in the same box
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 between two Delta rendering chips. Does show the need to handle multihead properly - particularly as one configuration of such cards is driving the 4 inputs of a 300dpi 3200x2400 display. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
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 those that when DRI is available use the DRI layer for 2D. This is an important part of the XFree/Xorg tradition. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Via DDX for DRI?
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 ati_drv.o and mach64_dri.so, r128_dri.so, radeon_dri.so, and r200_dri.so shows what I'm talking about. It would have been really confusing if r128_dri.so had originally been named ati_dri.so. I talked to VIA about this in the early days. They pointed at ati_drv.o as an example of why they should be able to use via as the top name for all their chipsets 8) Its also now crept into multiple vendors config/distribution tools and into users config files. The _dri.so file OTOH seems to be fair game without breaking anything, and I agree --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
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 Fbdev+DRI+text console+security+hotplug pile other than that it needs to be resolved. Hopefully the kernel summit in July will provide some more definitive answers on plans and once Linus has agreed to something (or destroyed all the ideas one by one 8)) it becomes easier to plan. In the shorter term however the sooner the current DRI is in the current X server the better. The kernel expects recent DRI, many users require it (eg for all modern laptops) with Linux and FreeBSD. Alan --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
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 (see GGI, or Eric Raymonds new kernel config tool) I do however object when he tries to use a research project as an execuse for slowing down a much needed merge of the current DRI code into Xorg. Thats an unrelated issue to the mesa solo work. Alan --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
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 drivers to do render better via DRI may make sense in some cases and in shorter than two years. As it is everyone is having to merge DRI and Xorg themselves right now to get a working useful tree for 2D and 3D. Getting all the code in the right places makes that work a lot easier, and means for example I can viably attack S3virge and SiS6326 support. (Which you'll want for mesa-solo eventually if only to understand the limits of hardware with only primitive 3D support). There are three main solutions to mode/cursors problem that no one can agree on: 1) leave fbdev in charge of mode setting and cursor, port it around to other architectures. For Linux I think everyone has accepted that you have to have a basic fb driver simply to do hotplug. Xorg however has to run everywhere. 3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the work as possible in user space and just pass final register values to the IOCTLs. DRM supports two platforms of the entire X world. In most of the proprietary cases the frame buffer layer is vendor controlled and may or may not be doing this. I guess Alan Coopersmith can comment on this for Solaris x86 for example. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
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 --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
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 - Keith's tiny X server work - Nanogui (2D down to about 50K RAM) - DirectFB (particularly strong at multimedia) For 3D you end up looking back at the mesa-solo work and it shares that same interest with the X over mesa people. We need a low-level kernel graphics API (much like Windows Unfortunately for a lot of hardware the entire design is different per card. You have to deal with an incredible range of hardware and its a tribute to the X DDX and XAA design how well it has coped with this. I've dealt with very little that X couldn't take a good shot at handling well. YUV422 only framebuffers being the one that gave it serious hiccups. Secondly every line of code you put in the kernel has to be audited, analysed and can introduce security holes or crash the machine. Its harder to debug and its harder to write in the first place. There are very good reasons (see the original DRI paper) for putting as much as you can in user space. The Mesa X work also tries to keep as much as possible in user space - including designs for mode computation by kernel-user callback. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
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 working xserver/mesa-solo this summer, even sooner if there was more help. This isn't relevant to the Xorg server. need to do is pull everything together. xserver on GL is an architecture that will be good for at least another ten years while the current XAA architecture is close to the end of it's life. You have no solution to non 3D heavy cards, you have no solution to non-Linux hardware platforms. Most of your linux ideas have been thrown out repeatedly as half-baked on multiple lists. mesa-solo is a *research* project. If it works out then in two years time its going to be rather cool. In the mean time trying to stop people doing important work to cripple what you perceive as a rival is just wrong. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PATCH: 2.6.7-rc3 drivers/char/drm/gamma_dma.c: several user/kernel pointer bugs
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 an Oxygen GMX somewhere, but last time I investigated the drivers didn't work anyway. Not that fixing the security bits isnt a good idea regardless. I'll try and test it at some point --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New i915 driver in cvs
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 licensed under an Xorg compatible license and going to go into that tree as well ? --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: clgd 5465
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 out of graphics stuff. I've got the 5465 docs somewhere as have many people. Its got a really cool 2D scaling blitter but the 3D stuff is a triangle painter. Having said that with the nearly working sis6326 work that Eric Anholt did its probably not that hard to knock out cs5465 dri if someone was really that crazy --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Via DDX for DRI?
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 wall with it is not. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Via DDX for DRI?
On Iau, 2004-06-03 at 22:35, Alex Deucher wrote: Ian, I don't know that there is a DDX that works with the Via DRI driver in mesa. As I recall, Erdi imported it for use with directfb or fbdev. I'm not sure anyone has actually tried to build X against the DRI/mesa trees. your best bet may 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 in the current Fedora 1 XFree86 4.3.x tree. I've not had time to finish up the 2.6/Xorg porting (real world got in the way) but plan to do so at some point (provisionally August) The DRI code probably needs a fair bit of fixing, I know several things don't work quite right in it. Alan --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
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 text consoles and it works currently. So clearly it is *not* too complex. If you have mode setting there is little else required since you can simply declare it to be the job of the client switched onto, to get its data back in order. Alan --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
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 documentation is plain wrong. You may be able to put X over another thin layer that does the security work and keeps virtual X servers apart. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
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 fancier stuff out of kernel as you've suggested but the basic VT and memory management just won't fit your model --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
