This isn't meant to criticize, but having to go on IRC to figure out that
SSH is down until further notice isn't exactly a great way to run a
service, I know it is the weekend (I do most of my work on the weekends)
but a mail to one of the mailing lists or something in the News page on
the main
The latest patch against the drmfntbl-0-0-1 branch of the DRM is at
http://www.skynet.ie/~airlied/patches/dri/drm_ftbl_latest.diff
This will be checked into the branch when fd.o gets sorted out...
It dumps:
DRIVER_CTX_[CD]TOR
HAVE_KERNEL_CTX_SWITCH
DRIVER_BUF_PRIV_T
DRIVER_AGP_BUFFERS_MAP
I
Dave Airlie wrote:
The latest patch against the drmfntbl-0-0-1 branch of the DRM is at
http://www.skynet.ie/~airlied/patches/dri/drm_ftbl_latest.diff
This will be checked into the branch when fd.o gets sorted out...
It dumps:
DRIVER_CTX_[CD]TOR
HAVE_KERNEL_CTX_SWITCH
DRIVER_BUF_PRIV_T
On Fri, 6 Aug 2004, Jon Smirl wrote:
This patch provides a new kernel API for access ROMs from device
drivers. If you're working on a driver that uses the ROM (most video
drivers) please give this patch a try and send some feedback/bugs.
pci_map_rom() - map the rom and provide virtual
On Gwe, 2004-08-06 at 18:16, Jon Smirl wrote:
fbdev is in exactly this model and it isn't causing anyone problems.
The simple rule is that if you want to upgrade fbdev past the current
version you have to do it in entirety. You do that for fbdev but
pulling bk://fbdev.bkbits.net/. But Joe user
On Sat, Aug 07, 2004 at 01:11:21AM +0100, Dave Airlie wrote:
fbdev only has one distribution vector - the kernel, DRM has multiple
distribution vectors, kernel, DRI snapshots, X releases, they all contain
their own DRM modules, also people with older kernels should be able to
which is the root
On Fri, Aug 06, 2004 at 05:54:52PM +0100, Keith Whitwell wrote:
Yes, while I support the current rework and de-templatization of the code, I
don't support any attempt to split the drm modules to try and share code at
runtime - ie. I don't support a core/submodule approach.
We had that
On Fri, Aug 06, 2004 at 12:54:26AM +0100, Dave Airlie wrote:
I guess one (unpleasant) way to make it work would be to add the version to
all the symbols in the device-independent layer. Instead of drm_foo you'd
have drm_foo_100 or drm_foo_101 or whatever. You could then have multiple
On Sat, Aug 07, 2004 at 02:31:07PM +0100, Alan Cox wrote:
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
Maximum size of a standard PCI ROM is 128KB. On non-x86 platforms the
code will pick the length up from the size of the PCI window. That
window has no limit.
On the other hand, map_rom_copy is only called by the device driver for
a board that has minimal PCI decoding. The PCI spec allows the
On Fri, 2004-08-06 at 16:09, Alex Deucher wrote:
did you have those problems with DRI cvs or are they new with xorg?
The streams code has be reshuffled a bit. also try with
option BCIForXv false (or something like that; I forget the exact name).
Don't see any changes with option
On Sat, 2004-08-07 at 16:43, albert vilella wrote:
I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps,
is just pulling the cvs and compiling?
Albert.
just pulling the cvs
apply this patch
http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff
( I just finished the
On Sat, 07 Aug 2004 17:43:23 +0200, albert vilella
[EMAIL PROTECTED] wrote:
I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps,
is just pulling the cvs and compiling?
download mesa cvs, xorg cvs, then apply my patch to xorg cvs, then
follow the mesa/xorg build instructions.
On Sat, 2004-08-07 at 17:08, Alex Deucher wrote:
On Sat, 07 Aug 2004 17:43:23 +0200, albert vilella
[EMAIL PROTECTED] wrote:
I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps,
is just pulling the cvs and compiling?
download mesa cvs, xorg cvs, then apply my patch to
Il Sat, Aug 07, 2004 at 07:59:29AM -0700, Jon Smirl ha scritto:
*This message was transferred with a trial version of CommuniGate(tm) Pro*
Maximum size of a standard PCI ROM is 128KB.
This is the maximun that kmalloc can allocate.
On non-x86 platforms the code will pick the length up from
All of the video ROMs I have are 48KB - 64KB in size. But, the copy
code is only triggered by the driver for older PCI cards with minimal
decoding. I am unaware of any video cards with this problem so they
won't make the copy. The only cards I seem to recall having this
problem are some older
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
--- Alan Cox [EMAIL PROTECTED] wrote:
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
On Sat, 07 Aug 2004 17:26:54 +0100, Sérgio Monteiro Basto
[EMAIL PROTECTED] wrote:
On Sat, 2004-08-07 at 17:08, Alex Deucher wrote:
On Sat, 07 Aug 2004 17:43:23 +0200, albert vilella
[EMAIL PROTECTED] wrote:
I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps,
is just
On Sad, 2004-08-07 at 18:40, Jon Smirl wrote:
We have to copy the whole thing when the driver tells us to. After we
copy the ROM the hardware is going to use the address decoder for
something else. There is no safe way to get back to the ROM again other
than to unload the device driver.
Good
On Fri, Aug 06, 2004 at 10:46:45AM -0700, Jon Smirl wrote:
There are three main ways to get a driver:
1) vendor release - most stable, I get one every two weeks
2) Linus bk - very up to date, not as well tested, once a day
3) copy DRM CVS into Linus bk - bleeding edge, hope you know what
21 matches
Mail list logo
