Re: Looking for some answers.
On Fri, Dec 17, 2004 at 03:31:13PM -0800, Mike Mestnik wrote: why doesnt radeon xinerama use mergedFB techniques to acieve its ends ? The only big hurdel is wather or not the heads share enuff videomemory for the entire FB. That, and not necessarily all cards support the framebuffer width necessary for mergedfb. -- Ryan Underwood, [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Looking for some answers.
On Fri, Dec 17, 2004 at 10:35:42AM +, Ian Molton wrote: Hi. Is MergedFB going to replace xinerama in the long run? For multi-head chips, probably. Even in that case, Xinerama is still useful as a more generic multi-head solution that works regardless of the underlying hardware. -- Ryan Underwood, [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIS 650 plans
On Mon, Dec 06, 2004 at 01:56:16PM +, Rogelio Serrano wrote: On Mon, 6 Dec 2004 05:25:22 -0800 (PST), Mr Leha Ivanov [EMAIL PROTECTED] wrote: Hi. Are there any plans to support SIS 650 Cards? Thanks. [snipped...] You know where to get better docs? People have tried to move heaven and earth looking for docs and nobody found anything worth a damn. Reverse engineering is the only option. Of course if its not illegal where you live. I think SIS provided binary drivers for these cards. The nice thing is that they left all the symbols in for you if you wanted to rev-eng it. I don't know of anything that would make the rev-eng illegal, unless you agreed to a EULA prohibiting it or else you end up violating a patent or something. -- Ryan Underwood, [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
s3 virge docs
Found this random link which some folks may be interested in: http://members.shaw.ca/mm99mm/S3_Virge_programming_spec.html -- Ryan Underwood, [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
On Sun, Oct 24, 2004 at 08:10:14PM +0200, Bernardo Innocenti wrote: IANAL, but reverse engineering is perfectly legal here in Europe and probably even in the USA if your goal is achieving compatibility. Have to be careful - most folks doing reversing do a clean-room implementation (1 person reverses and creates a spec, another person develops based on the spec) to avoid creating some software that might be called a derivative work of the original. I can freely use the S3TC extension here because it's not (yet) patentable. Any US developer could write it and even compile it, as long as he doesn't sell it in his country. Use of a patented algorithm without paying the license fee is a patent infringement. Even if it's your own code on your own machines. Selling or distributing it doesn't even enter into the picture as far as the US legality goes; it only affects the damages which would be awarded in a patent suit. It's also better in general for you not to check whether what you're doing would infringe any patents or not, because damages for willful infringement are usually significantly higher. I think the general rule of thumb regarding patents is to play dumb until you haven't any choice (receive a CD, or patent is somehow brought to your attention otherwise). -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Savage DRI DDX to xorg merged
On Tue, Sep 14, 2004 at 12:26:22AM -0400, Alex Deucher wrote: Savage dri works quite well (again) on xorg 6.8, except on xv video mode with some mpegs, as I reported at first time. I'm working on a major rework of the savage driver to address Xv and several other features (dvi support, dualhead, etc.). I just picked up a savage2000 on ebay. Has anyone checked the 2D component yet? Also curious if anyone has done any begging for docs on the 3D/video stuff yet. I think it's different from the rest of the savage family. The 3d core has TL and bump mapping and I don't know of the other chips do. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: New proposed DRM interface design
On Sun, Sep 05, 2004 at 11:33:53AM -0400, 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? I was planning on adding pieces of the existing fbdev code to DRM in order to implement printk from the kernel. It seems silly for me to rewrite 10,000 lines of code just to make it BSD licensed when BSD isn't even going to use the code. Is the code in question attributed to a single developer or to a horde? I only have a 2.4 kernel handy, so I can't check. If it's a single developer or just a few, you could ask them for permission to put it under a less restrictive license. Petr Vandrovec gave that permission for his components of the matroxfb code. A lot of times the FB people don't really care about the license and slap GPL on it just because that's the default thing to do for code going into the Linux kernel. It doesn't necessarily mean that they would only grant permission for the code to be used in GPL scenarios. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Xorg] DRI merging
in userspace compared to the kernel. One problem compared to a kernel approach I see is locking. If some process is waiting for a lock and its thread with the arbiter is sleeping, and the resource becomes free, how do I wake it up? Send it a signal? So the idea is that the kernel has nothing at all to do with graphics besides some security related stuff if necessary. Instead of a bunch of processes competing for the hardware without having knowledge of what the others are doing or what state the hardware is in, place a trusted userspace arbiter in control of access to the hardware. Root-owned processes could circumvent the arbiter, and individual processes are not obligated to share low-level resources (like FB or MMIO registers) if they are granted access, so it is a cooperative approach. But for normal processes using abstract resources, the arbiter can enforce whatever policy it feels like for a particular piece of hardware to ensure that it cannot be caused to fail by numerous processes competing for its resources. A library would be wrapped around the arbiter to make access to it transparent as well as provide mid level APIs for various common graphics tasks. Individual applications like Mesa would still have control over e.g. the structure of DMA buffers, and then they call a arbiter library function to dispatch a buffer, competely ignoring the state of the hardware because the arbiter is taking care of serialization and locking as well as checking the validity of the buffers if desired. I just mashed this down so its probably half baked. Any thoughts? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: S3TC/DXTC patch status
On Thu, Jun 03, 2004 at 01:34:58AM +0200, Roland Scheidegger wrote: [EMAIL PROTECTED] wrote: Hi, I'd like to know where is the texture compression now? Has it been integrated to the mesa tree or is it still provided in a separate library ? It is still in a separate library, the legal issues have not changed. Is it possible to integrate s3tc but ship with it disabled, similar to how FreeType operates regarding the hinting patents owned by apple? Then individual distributors can choose whether or not to enable it depending on their location. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Xorg] DRI merging
On Sat, Jun 12, 2004 at 11:40:42AM -0400, Alex Deucher wrote: multi-head and ryan's latest work removes the hallib requirements from the matrox driver, Not yet. Hopefully soon. :) -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
using g400 via mmio
Hi,
I'm playing around with my G400 using mmio access. Can someone tell me
what I'm doing wrong? Writing to the registers doesn't produce a seg
fault (so it seems that it would be mapped correctly), but reading back
from them afterwards gives me either strange values or zero.
(Ignore the WARPREG* reading, that was only a test to see if they really
were W/O.)
Poking a value into any of the other registers has no effect on what is
read back later. Some of them are explicitly marked as R/W, but I can't
tell from the databook whether or not the value I write in that register
should be latched and available for subsequent reads, or if some
altogether different value is typically made available for reading from
that reg.
Any PCI posting should be flushed out by the read, and I made sure that
access to MMIO space is enabled by hitting a register in the pci config
space. Curiously, making changes to PCI config space seems to be fine,
even while I am banging my head on the mmio. (If I disable MMIO access
there, then any reads from MMIO space obviously return 0x.)
I tried using msync, munmap, etc, and none of that seems to have an
effect. I'm slowly beginning to suspect that R/W doesn't mean what I
think it means with respect to MMIO registers.
--
Ryan Underwood, [EMAIL PROTECTED]
#include stdlib.h
#include stdio.h
#include assert.h
#include sys/mman.h
#include pci/pci.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#define MGA_VENDOR 0x102b
#define G400_DEVICE 0x0525
#include warp_hw.h
#define MGAREG(x) *(volatile u32 *)(MGABASE1+x)
#define MGA_LEN 0x4000
void init_warp_regs(volatile void *MGABASE1) {
int i;
/* memset(MGABASE1+WARPREG(0), 0, 64*4); */
fprintf(stderr, Seeding WARP regs...\n);
for (i = 0; i 64; i++) {
MGAREG(WARPREG(i)) = i+1;
fprintf(stderr, [%d]:\t%8lx , i, i+1);
if (!((i+1)%4)) fprintf(stderr, \n);
}
// fprintf(stderr, Setting WMISC (0x%08p) to 3...\n, MGABASE1+WMISC);
// MGAREG(WMISC) = 3;
// fprintf(stderr, WMISC (0x%08p) is %d\n, MGABASE1+WMISC, MGAREG(WMISC));
fprintf(stderr, Setting WIADDRNB (%08p) to 0x3...\n, MGABASE1+WIADDRNB);
MGAREG(WIADDRNB) = 0x3;
fprintf(stderr, WIADDRNB (%08p) is %d\n, MGABASE1+WIADDRNB, MGAREG(WIADDRNB));
fprintf(stderr, Setting C2CTL (%08p:%08lx) \n, MGABASE1+C2CTL, MGAREG(C2CTL));
MGAREG(C2CTL) = C2CTL_C2EN;
fprintf(stderr, C2CTL (%08p) is %d\n, MGABASE1+C2CTL, MGAREG(C2CTL));
}
void dump_warp(volatile void *MGABASE1) {
int i;
fprintf(stderr, Display WARP0 regs:\n);
for (i = 0; i 64; i++) {
fprintf(stderr, [%d]:\t%8lx , i, MGAREG(WARPREG(i)));
if (!((i+1)%4)) fprintf(stderr, \n);
}
fprintf(stderr, WARP0 Interrupt %s\n, (MGAREG(IEN) WIEN)? enabled:disabled);
fprintf(stderr, WARP0 Cache-miss Interrupt %s\n, (MGAREG(IEN) WCIEN)? enabled:disabled);
fprintf(stderr, WARP1 Interrupt %s\n, (MGAREG(IEN) WIEN1)? enabled:disabled);
fprintf(stderr, WARP1 Cache-miss Interrupt %s\n, (MGAREG(IEN) WCIEN1)? enabled:disabled);
fprintf(stderr, Drawing engine status: %s\n, (MGAREG(STATUS) DWGENGSTS)? busy: idle);
fprintf(stderr, WARP0 status: %s\n, (MGAREG(STATUS) WBUSY)? not idle: idle);
fprintf(stderr, WARP1 status: %s\n, (MGAREG(STATUS) WBUSY1)? not idle: idle);
fprintf(stderr, WARP BFIFO Path: %s\n, (MGAREG(STATUS) WARPBFPATH)? WARP1: WARP0);
fprintf(stderr, WARPFIFO Input Path: %s\n, (MGAREG(STATUS) WFIPATH)?
WARPFIFO1: WARPFIFO0);
fprintf(stderr, WARPFIFO Output Path: %s\n, (MGAREG(STATUS) WFOPATH)?
WARPFIFO1: WARPFIFO0);
fprintf(stderr, WARP microcode address: 0x%lx\n, MGAREG(WCODEADDR) 0xff00);
fprintf(stderr, WARP microcode caching %s\n, (MGAREG(WMISC) (1 0))? enabled:disabled);
fprintf(stderr, WARP microcode load strategy: );
if (MGAREG(WMISC) (1 0)) {
if (MGAREG(WMISC) (1 1)) {
fprintf(stderr, bus mastering\n);
}
else {
fprintf(stderr, interrupt\n);
}
}
else {
fprintf(stderr, direct load\n);
}
}
int main(int argc, char**argv) {
volatile void *MGABASE1;
struct pci_access *all_devices;
struct pci_dev cfg;
struct pci_dev *cur;
int fd, i;
u32 mgabase_addr = 0;
u32 ret;
assert(!getuid());
iopl(3);
/* Scan PCI buses for G400 */
all_devices = pci_alloc();
all_devices-numeric_ids = 1;
pci_init(all_devices);
pci_scan_bus(all_devices);
cur = all_devices-devices;
for (i = 0; ; i++) {
if (cur[i].vendor_id == MGA_VENDOR cur[i].device_id == G400_DEVICE) {
printf(found MGA: irq %d\n, cur[i].irq);
memcpy(cfg, cur[i], sizeof(struct pci_dev));
mgabase_addr = pci_read_long(cur[i], 0x14) PCI_ADDR_MEM_MASK;
break;
}
if (cur[i].next == NULL) break;
}
if (mgabase_addr == 0) {
fprintf(stderr, MGABASE1 not found\n);
exit(EXIT_FAILURE);
}
fprintf(stderr,MGABASE1: 0x%lx\n, mgabase_addr);
fprintf(stderr,MGABASE2: 0x%lx\n, pci_read_long(cfg, 0x10));
fprintf(stderr,DEVID: 0x%lx\n, (ret = pci_read_long(cfg, 0x00)));
fprintf(stderr,DEVCTRL: 0x%lx\n, (ret = pci_read_long(cfg, 0x04)));
if (!(ret
[Dri-devel] Re: more evil firmwares found
On Sun, Apr 25, 2004 at 11:57:28PM -0500, Ryan Underwood wrote:
I think I'll be doing some footwork on this one.
I wrote a quick program to parse out the microcode from the XFree86
mga_ucode.h files. From here a disassembler can be written if we can
ever figure out the op codes. The DDK says that they are 64-bits wide
and 64-bit aligned. It seems that might be incorrect though. There are
a lot of dupes if you examine the values at a width of 32-bits.
--
Ryan Underwood, [EMAIL PROTECTED]
#include stdlib.h
#include stdio.h
#include errno.h
#include warp_opcodes.h
#define OPCODE_SIZE 8
/* Parse the XFree86 MGA ucodes and generate a source listing. */
static inline int whitespace(char c) {
return (c == '\n' || c == '\r' || c == ' ' || c == '\t');
}
static char *slurp(char *src, char *what) {
char *p = src;
int i;
while (p[0] != what[0]) {
p++;
if (*p == '\0') return src;
}
for (i = 0; what[i] != '\0'; i++) {
if (p[i] != what[i]) {
i--;
break;
}
}
src = p + i;
return src;
}
static int disassemble_warp(int *ip, unsigned char *opcode) {
int i;
char buf[5];
printf(%x:\t, *ip);
/* for now just print op */
for (i = 0; i OPCODE_SIZE; i++) {
printf(%2x , opcode[i]);
}
printf(\n);
*ip += OPCODE_SIZE;
return 1;
}
int main(int argc, char**argv) {
FILE *inp;
char *filebuf, *p;
int done = 0;
int error = 0;
int size;
if (argc 2) {
fprintf(stderr, Need an argument; a filename or '-' for stdin.\n);
exit(EXIT_FAILURE);
}
/* if (argv[1][0] == '-') {
fprintf(stderr, Reading from standard input...\n);
inp = stdin;
}
else {
*/
if ((inp = fopen(argv[1], r)) == NULL) {
perror(fopen);
exit(EXIT_FAILURE);
}
fprintf(stderr, Reading from file %s...\n, argv[1]);
/*
}
*/
if (fseek(inp, 0, SEEK_END) == -1) {
perror(fseek);
exit(EXIT_FAILURE);
}
if ((size = ftell(inp)) == -1) {
perror(ftell);
exit(EXIT_FAILURE);
}
if (fseek(inp, 0, SEEK_SET) == -1) {
perror(fseek);
exit(EXIT_FAILURE);
}
filebuf = (char*)malloc(size+1);
if (filebuf == NULL) {
perror(malloc);
exit(EXIT_FAILURE);
}
fread(filebuf, size, 1, inp);
if (ferror(inp)) {
perror(fread);
error = 1;
goto cleanup;
}
if (fclose(inp) == EOF) {
perror(fclose);
}
filebuf[size] = '\0';
p = filebuf;
char cur_vname[255];
int vname_next = 0;
int data_next = 0;
while (!done *p != '\0') {
while (whitespace(*p)) p++;
if (vname_next) {
if (*p == '*') { /* declared as pointer */
p++;
}
char *q;
q = slurp(p, );
strncpy(cur_vname, p, q-p);
cur_vname[q-p] = '\0';
fprintf(stderr, Parsing variable %s...\n, cur_vname);
p = q;
p = slurp(p, {);
vname_next = 0;
data_next = 1;
continue;
}
if (data_next) {
int ip = 0;
unsigned char cur_op[OPCODE_SIZE];
int index = 0;
printf(%s:\n, cur_vname);
while (*p != '}') {
if (whitespace(*p)) {
p++;
continue;
}
if (*p == ',') {
p++;
continue;
}
if (strncmp(p, 0x, 2) == 0) { /* next component is ready */
int i;
long int val = strtol(p, p, 16);
if (errno) {
perror(strtol);
goto cleanup;
}
cur_op[index] = (unsigned char)val;
index++;
if (index == OPCODE_SIZE) {
index = 0;
if (!disassemble_warp(ip, cur_op)) {
fprintf(stderr, Error disassembly:\n);
for (i = 0; i OPCODE_SIZE; i++) {
fprintf(stderr, %x, cur_op[i]);
}
fprintf(stderr, \n);
}
}
}
else {
char err[50+1];
strncpy(err, p, 50);
err[50] = '\0';
fprintf(stderr, Malformed input at:\n%s\n, err);
error = 1;
goto cleanup;
}
}
data_next = 0;
p = slurp(p, });
p = slurp(p, ;);
printf(\n);
}
if (strncmp(p, /*, 2) == 0) { /* start comment */
fprintf(stderr, slurping a comment\n);
p = slurp(p, */);
continue;
}
else if ((strncmp(p, static , sizeof(static)) == 0)
|| strncmp(p, unsigned , sizeof(unsigned)) == 0)
{
p = slurp(p, );
continue;
}
else if (strncmp(p, char , sizeof(char)) == 0) {
vname_next = 1;
p = slurp(p, );
continue;
}
else { /* advance */
// fprintf(stderr, advancing\n);
p++;
}
}
cleanup:
free(filebuf);
if (error) {
fprintf(stderr, Errors were encountered.\n);
exit(EXIT_FAILURE);
}
exit(EXIT_SUCCESS);
}
signature.asc
Description: Digital signature
[Dri-devel] Re: more evil firmwares found
On Mon, Apr 26, 2004 at 02:49:36AM -0500, Ryan Underwood wrote: I wrote a quick program to parse out the microcode from the XFree86 mga_ucode.h files. attaching sample output. seems that g200 and g400-mt ucodes are much bigger than g400 ucodes in general. -- Ryan Underwood, [EMAIL PROTECTED] ucode_out.gz Description: Binary data signature.asc Description: Digital signature
Re: [Dri-devel] Continuing 3dfx Voodoo 3 3000 drivers
On Thu, Apr 22, 2004 at 02:32:11AM -0300, pablo.nogueira.vale wrote: I've a 3dfx Voodoo 3 3000 board and I want to continue the driver for it, and update it. Good, get the documentation available online (google for voodoo3.pdf) and check the tracker for existing bugs against it that you could help address. http://sourceforge.net/tracker/?group_id=387 I like to develop in assembly, so I think it will not be a too hard task to do it. You can implement platform-specific optimizations in assembly, but please make sure they are clearly #ifdef i386 or something similar, and that equivalent C implementations are available. All the world's not a 386, especially with hardware who are implemented in PCI form. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] tdfx driver
On Wed, Apr 21, 2004 at 02:42:48PM +0200, Vykupitel wrote: Hello, I've got problem with tdfx driver.Someone told me that tdfx driver development is halted,but I need to add one type of card to it.I have Daytona card which is prototype of Voodoo4 4200 with VSA-101 which support DDR RAM and tdfx didn't recognize it. Is still there any developer that could fix it? can you take a physical picture of this card and post it? I have never seen such a card. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 08:16:36PM +0100, Alan Cox wrote: On Sad, 2004-04-17 at 19:40, Ryan Underwood wrote: Of course, if the legal advice you refer to was specifically aimed at the firmware scenario, where you have a blob of who-knows-what that does not execute on the host embedded into a driver binary, then I'm not one to argue with that. It was specifically in response to the question about firmware, and whether it would be better if firmware was seperated. I don't know of any direct case law on embedding firmware and at what point it isn't mere aggregation So your advisor is saying that such a work is undistributable under the GPL, or are they saying that it is not distributable at all? I'm also curious if they would draw the same conclusion if you had some form of interpretable bytecode that is embedded into the binary. It doesn't run on any CPU, but nevertheless is classified software by most definitions since it executes in a virtual machine. You might say then that the bytecode is not the preferred form of modification according to the GPL, but if I wrote an interpreter and no other tools to go with it, it has no other form in which it can be modified. This is borderline pedantry, but boundary cases must be considered if we are to make wise decisions. I don't think any of this really addresses the DFSG though. Some Debian folks are removing firmware which is freely distributable and not being combined/aggregated with GPL drivers, on the basis that it is software and thus must be DFSG-free according to the social contract. One requirement to be DFSG-free is that source must be made available, so these firmware don't satisfy it and are removed. My opinion is that this only makes sense when the target is known to be a general purpose computer and the firmware image is known to contain a program that is executed by its CPU. Otherwise, it could simply be a configuration list that is parsed by the device, or a memory initialization image, or a dispatch table, or something similar, and rejecting such things on the basis that they are *suspected* to be software without source seems to be counterproductive. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sun, Apr 18, 2004 at 09:20:00AM +0100, Alan Cox wrote: Otherwise, it could simply be a configuration list that is parsed by the device, or a memory initialization image, or a dispatch table, or something similar, and rejecting such things on the basis that they are *suspected* to be software without source seems to be counterproductive There is no difference between the two, but this is getting very off-topic Its on-topic because the OP's work was generated specifically from the discussion on the Debian lists that I referenced. I still don't see where the boundary is drawn between data (which requires no source to be DFSG-free) and embedded executable code (which requires source to be DFSG-free). It seems that the interpretation is arbitrary depending on what 'feels' right in a particular case. I've no contest with people doing work to make things more flexible, but in this case the OP's work is being done because the unidentified matter is to be removed from the distribution, due to its suspected code-without-source nature. Why not do this work simply as a precursor to the event where someone identifies this binary blob as code-without-source in the future, and defer the actual removal to that future date if it ever arrives? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 09:36:24AM +0100, Alan Cox wrote: This is the answer I was given by lawyers. The analogy they use is an interesting but sensible one. If I add a chapter to a book it is clearly a derivative work, if I bundle the one work with a second pamphlet containing the chapter I wrote then it is not. It seems digging up some case law on the matter would be better than using analogies. Firmware could already be considered to be the pamphlet that is bundled with the book (the driver) because the firmware is not part of the driver in terms of functionality; it happens to be bundled with the driver because that is the most convenient way to get it into the hardware. Execution of the driver code never reaches the firmware and could not because it is not encoded in the instruction set of the host that the driver is running on. Of course, if the legal advice you refer to was specifically aimed at the firmware scenario, where you have a blob of who-knows-what that does not execute on the host embedded into a driver binary, then I'm not one to argue with that. I don't think its zealots so much as appropriate legal practice. In the Linux case we now have a good hotplug firmware loading interface and drivers can practically ask for specific firmware. It also reduces the unswappable kernel size Sure. I won't argue with people that are making the existing systems more flexible. My beef is mainly that a lot of people are considering sourceless firmware to be outside the DFSG, which amounts to an inconvenience to users for a dubious political gain. But that is off-topic for dri-devel probably. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 03:33:16PM +0200, Michel Dänzer wrote: I don't think such a complicated scheme is needed? Just encode the microcode version in the filename and try to load any supported version, from most to least preferred? I think that's what I meant. Point being, have the kernel call out to a userspace loader on the driver's behalf, instead of the user running a loader like Nathaniel's in an init script or something. I was also reminding folks of the importance of versioning of the driver vs the firmware, because one of his comments seemed to imply that you could upgrade the microcode to a new version without changes to the driver. This is not always true because the command interface may change from revision to revision of the microcode. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 03:03:04AM +0200, Michel Dänzer wrote: It allows for the microcode to be updated without replacing the kernel, which is not a bad thing anyway. But changing the microcode would change the driver-chip interface anyway. So you'd have to update the driver too. Keeping the driver and the userspace loader in sync might be...erm.. painful. If a userspace approach to firmware loading is pursued, perhaps a better approach is like the modprobe approach. When the XFree86 driver for a piece of hardware initializes, it would do a kernel probe for the firmware for this device, corresponding to the particular version of the driver that is running. The kernel would call a firmware loading binary (like it calls /sbin/modprobe or whatever is in that /proc entry) telling it what driver is asking and what version of the driver. Based on that information, the userspace loader can decide which version of the microcode to load up. If that version is not available, exit with failure and the kernel should then return failure to the application, so it knows that the proper microcode that particular driver version was written against was unable to be found, and to disable features which would require a loaded microcode. I'm not sure it ever has changed or will change... we both know the background of this; IMHO it's an inconvenience for users for little or no gain of freedom. Well, microcode without source has been a big topic on debian-devel recently. There seems to be 3 interpretations under DFSG: 1) Binary only firmware under a license which doesn't require redistribution of source code is ok (i.e. a BSD license), but GPL licensed stuff is no good because no way to satisfy GPL. 2) Binary only firmware as well as GPL licensed stuff is ok. Here we are arguing intent on the part of whoever released the binary only code under GPL, and saying that they would be laughed out of court if it ever came to them suing a distributor for breach of GPL. 3) Neither of these is ok, must go into non-free because binary-only firmware doesnt meet DFSG (no source) regardless of its license. Either whole driver must go into non-free, or a crippled driver is provided in main and a userspace loader in non-free to add the missing functionality. 3 is a rather zealous approach, but seemed to be the approach that the do-ers on this issue are taking. I sympathize with the idealists on this issue, but I can't help but feel that this is impractical in the short run. I would love if Matrox gave me some microcode programming info for their WARP engine in G-series (could implement a TL pipeline stage for instance), but I think inconveniencing users in this way is the wrong way to put pressure on the vendor to be more open (if that is the goal). These things are not general purpose computers, and I think the DFSG should only apply to software that is run on a general purpose computer. You could say that a video card or a random USB microcontroller may or may not be a Von Neumann machine. But it is probably not even close to Turing complete. Of course we don't know that without the specifications. But I don't see the point of applying DFSG to things that are not, or not known to be, general purpose computers. As long as the microcode is legally redistributable, I dont have a problem with it. (Granted, some of the microcode included with the Linux kernel seems not to be freely redistributable, and that is obviously a problem that some have been overlooking.) -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] Building DRM for 2.6.3. And mach64 randr.
On Mon, Mar 08, 2004 at 01:25:28AM +, Dave Airlie wrote: all the mach64 really does is triangle and texturing, not much else.. so it depends on what you run on it to decide if it goes faster.. tuxracer certainly does :-) Oh, and you can have any one you want of hardware fog and alpha; take your pick. :) -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] Savage DRI hangs when loaded by an application
On Sat, Feb 14, 2004 at 11:46:19PM -0800, Alex Deucher wrote: To elaborate on what felix said, savage2000 is a different beast than any of the other savages. regarding the 2D driver, I have no idea how its bitmap descripters are laid out. The 3D engine is a whole nother ball of wax... if you want to play around with it you may be able to get something working, but that assumes its 3D engine operates similar to prosavage or savage4. Just knowing how many weird little differences there are in the 3D engines of savage4 and prosavage does not bode well for savage2000 support. Savage2000's 3D engine has a TL unit that, IIRC, S3 never even could get working right. I think it worked in D3D but they disabled it in OpenGL due to hardware problems or something. So there would be another unique aspect to the Savage2000 compared to the rest of the Savage line. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] Slow Mtex in DRI
On Sun, Feb 15, 2004 at 03:50:54PM +0200, Ville Syrjälä wrote: A comment in the r128 driver sources makes me think the hardware can support this but someone would need to add support for a new vertex format into the templates. For mga we would need better microcode to support this. The hardware could do it but the microcode is holding us back :( Is it possible to extract a newer microcode from the windows drivers? This was the approach used by the dxr3 people since Sigma wasn't giving microcode to anyone. But I wonder if mga can even do this under windows. I guess it would only be G400+, since G200 only has one WARP so it seems that it wouldnt be able to do hardware multitexture. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] Savage DRI hangs when loaded by an application
On Sun, Feb 15, 2004 at 08:02:51AM -0800, Alex Deucher wrote: Savage2000's 3D engine has a TL unit that, IIRC, S3 never even could get working right. I think it worked in D3D but they disabled it in OpenGL due to hardware problems or something. So there would be another unique aspect to the Savage2000 compared to the rest of the Savage line. In that case I seriously doubt it will work with the current driver. I was wrong; it's the other way around: http://techreport.com/news_reply.x/743 Apparently the card advertised hardware TL on the box, and Diamond assumed they would be able to get it working in driver upgrades after the product shipped. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] Trying to compile savage.o DRI module
Hi George, On Sat, Jan 31, 2004 at 03:07:37PM +0100, George Lengel wrote: My questions. At http://dri.sourceforge.net/doc/DRIcompile.html it seems to imply in order to compile the DRI stuff, I need to compile my kernel. What is the reason for this? Is it simply to ensure the kernel has certain things loaded? No, this is not usually necessary. Most modern kernels have the necessary support (agpgart, mtrr, etc) already included. You will need to compile the DRM modules against your current kernel though. Make sure you use the same compiler as your kernel was built with, or you will have problems. (You can usually find that out from the top of dmesg.) Also, in reading the mail list, it seems implied that I have to compile XFree in order to use a DRI module. Is this also absolutely necessary? Is running the 4.3.99 binary good enough? Right now all I have pulled from CVS is the savage branch. That should be fine. Pull Mesa and xc from DRI CVS, edit xc/config/cf/host.def to point to the Mesa directory, and in xc/Makefile comment out this line: $(MAKE_CMD) $(MFLAGS) $(WORLDOPTS) World Then you can build the drivers separately wherever they reside in the tree: xc/programs/Xserver/hw/xfree86/drivers for the 2D driver xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel for the DRM-modules xc/lib/GL/mesa/drivers/dri for the Mesa hardware support modules That should get you started. Note that I don't have any experience with the savage driver but this is what I use for other DRI work. If you have any other questions feel free to post here. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] Trying to compile savage.o DRI module
On Sat, Jan 31, 2004 at 04:19:45PM -0600, Ryan Underwood wrote: That should be fine. Pull Mesa and xc from DRI CVS, edit xc/config/cf/host.def to point to the Mesa directory, and in xc/Makefile comment out this line: $(MAKE_CMD) $(MFLAGS) $(WORLDOPTS) World Then you can build the drivers separately wherever they reside in the tree: You also need to make World in there before going to the different parts of the tree to build stuff. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Jan 21, 2004 at 03:24:23PM +0100, Michel Dänzer wrote: Well, yes, it's hard to package future changes. :) (BTW, the XFree86 tag is only relevant in XFree86 CVS, and Ville's fixes likely happened after 2003/10/05.) Oops, you're right. They were from November. PS: You get the trunk with -r HEAD or just no -r at all. Now this is going to sound doubly stupid, but I *swear* I checked out CVS HEAD yesterday, and all that showed up was FreeType and X-TrueType stuff along with some basic directory structure. Which is why I went searching for further instructions and thought perhaps I was supposed to use -rtrunk instead. I've just checked a complete copy and am building it now. Thanks for the tutelage. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
Ville, On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote: I can't reproduce any font corruption with crack-attack (or any other gl app) and quake2 just segfaults when I try to run it. Maybe it doesn't like to run with the demo pak file... But running quake3 and crack-attack at the same time does cause some really nasty texture corruption. They appear to step on each others' textures... Just to let you know, it appears the RENDER bug has been solved. I think I didn't properly replace the driver before. :) However, I was doing my own driver hacking, so I was forced to replace it correctly this time. The only problem I have with the mga driver right now is lack of mouse cursor in UT, though there is a claim in bugzilla that you fixed it. Do you have any details on the fix? On another topic, do you use a dualhead G400? If so, are you able to properly use DPMS on the second head? I don't run XFree86 except when trying to hunt DRI related bugs. It's been well over a year since I really used XFree86 and I honestly don't remember if DPMS ever worked with the second head. I don't have a second monitor to test right now. I just uploaded a patch to the bug tracker that makes DPMS work on the second head among other things (i2c/maven related). -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[Dri-devel] GL_ATI_envmap_bumpmap
Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Jan 21, 2004 at 01:30:15AM +0100, Michel Dänzer wrote: On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote: Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. Just look at the package version... if you want to follow or even do development, my snapshot packages aren't for you, use CVS directly. Right, I just used them as a matter of convenience, no having to maintain separate XFree86 installation and such. Rebuild, dpkg -i *.deb, and test. Your package version is 2003.10.05-2 which is much newer than the above CVS tag. Seemed strange to me that there would be no trunk merges in 7 months, but I guess that is the case. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] GL_ATI_envmap_bumpmap
On Wed, Jan 21, 2004 at 12:23:17AM +0200, Ville Syrjälä wrote: On Tue, Jan 20, 2004 at 03:47:49PM -0600, Ryan Underwood wrote: Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? Last time I looked Mesa didn't support this extension. My plan was to add bumpmap support to the mga driver if/when someone added the relevant Mesa bits... You're right, I was looking only at glext.h. My intent was to implement it to the mga driver too because it is sort of a unique functionality that can create some nice eye candy. A secondary intent was to implement DX6 EMBM in WINE and pass it through to this extension if available. That way you could run DX6+ games that utilize EMBM in WINE. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Jan 21, 2004 at 01:30:15AM +0100, Michel Dänzer wrote: On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote: Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. Just look at the package version... if you want to follow or even do development, my snapshot packages aren't for you, use CVS directly. I remembered another reason I used your package. When I tried to check out DRI CVS, I used: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri -z4 co -rtrunk xc trying to get the trunk branch as CvsBranches in the Wiki mentions. However: cvs [server aborted]: no such tag trunk How should this preferably be done? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 02:13:50PM -0800, Alex Deucher wrote: --- Ryan Underwood [EMAIL PROTECTED] wrote: [snip] No code was copied, only some defines. I need other people to check the code and tell me if it will break on other video cards. I only have a G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc which need to be tested, and some changes were made to the main driver code too so there is a potential I made a mistake that would affect even non-G series matrox cards. The main thing I am worrying about is how some of the maven registers I used will behave on different cards. Right now I am trying to get DDC working on port 2 so I can be sure my i2c code is 100% correct. You might ask Petr or one of the kernel fbdev or directfb developers. they might be able to help you. unfortunately all my matrox cards have either died or or are no longer around :( I got DDC working. It was my second monitor that was the problem; its EDID data seems to be corrupt. It doesn't even work on the first head, and I can read my first monitor's EDID on the second head, so looks like we are in business. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] Re: radeon problem
On Mon, Jan 12, 2004 at 06:01:42PM -0600, Stephen Waters wrote: I can't figure out why else strace would just stop logging and exit normally... here's my workflow: 1) /etc/init.d/gdm restart 2) ctrl+alt+f1 to get back to terminal 3) ps x |grep X 4) strace -p pid_of_X 5) alt+f7 6) log into gdm 7) crash 8) back to VT1 where I notice that strace exited normally without any useful information leading me to believe that it exits at login due to some forking thing. Is there something smarter I should do? If it really is forking somehow, using -f on strace should follow the forks. But I have a feeling that isn't what is really going on. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[nemesis-lists@icequake.net: Re: [Dri-devel] MGA font corruption revisited - now reproducible]
[reposting... attachments caused message to be killed] On Wed, Dec 10, 2003 at 12:53:53PM +0200, Ville Syrjälä wrote: If you remove/comment out the following line $(MAKE_CMD) $(MFLAGS) $(WORLDOPTS) World in the top Makefile make World shouldn't actually build anything. After that you should be able to build only the driver. I uploaded my patched mga_drv.o to my website http://www.sci.fi/~syrjala/dri/ so you might want to try that before building yourself... Here is a long story, prepare yourself. I ran crack-attack and the corruption didn't occur this time. After running quake2, there was still another problem. The fonts themselves are not corrupted, but the AA fonts, instead of having the normal background behind them of whatever the application puts there, have a black square for the background. It is almost like the data in that square was erased. Again, running UT and exiting it, and then causing the application to redraw, clears that problem up. I attached a screenshot of what it looks like. Like the font-corruption problem, this happens across all applications that use Xft-rendered fonts, there is a black background behind the rendered area in every place. later: I ran crack-attack once as mentioned and the corruption didn't occur, leading me to think it was fixed. Then I ran it again later after running quake2, and the corruption occurred again. :( The fonts are only corrupted after being redrawn. By that I mean immediately after exiting crack-attack, everything looks fine, but if I highlight a user in licq, his entry is immediately corrupted, and remains corrupted. Now I ran quake2 again, and the crack-attack corruption is gone in what seems to be the portion of the licq window that would have been overlaid by the GLX framebuffer (causing redraw of that stuff). It is replaced by the quake2 blank background corruption instead in those places. If I then highlight the other users users, they then change from crack-attack corruption to quake2 corruption -- the font is correct but the background is black. I attached screenshots of both the crack-attack corruption as well as the quake2 corruption so you can see what I talk about. It is strange that running UT clears up both of the corruptions reliably. Can you run crack-attack and quake2 to reproduce it? http://dbz.icequake.net/share/crack-attack-corruption.jpg http://dbz.icequake.net/share/quake2_corruption.jpg http://dbz.icequake.net/share/q2.log.bz2 I have also used UT to clear up the state when a SDL application crashes without parachute and leaves the mouse unable to be used. (I don't know of any other way to recover the mouse when it is not responding to input; at least I can use keyboard navigation to start UT from window manager's menu.) Seems like UT does some things correctly that other applications are not doing. Something else, 4 out of 5 times, quake2 does not cleanly exit, strace ends here (10 is the fd of /dev/dri/card0): [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe0b0) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0x4008642b, 0xbfffe510) = 0 [pid 12025] ioctl(10, 0x4008642a, 0xbfffe138) = ? ERESTARTSYS (To be restarted) [pid 12025] +++ killed by SIGKILL +++ It hangs on that last ioctl which is where I kill the application. How do I translate those ioctls into hardware commands so I know where to look for the problem? I guess mga_dri.so is sending some command to the DRM layer that it never bothers to return from here. I attached the whole strace if you are curious. On another topic, do you use a dualhead G400? If so, are you able to properly use DPMS on the second head? My second monitor blanks from the X screen blanker, but remains on, consuming power. The first one powers off as expected. I posted earlier about this to the XFree86 list, including a list of changelog entries corresponding to second-head DPMS on G400, but didn't elicit any responses. -- Ryan Underwood, [EMAIL PROTECTED] - End forwarded message - -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote: I don't run XFree86 except when trying to hunt DRI related bugs. It's been well over a year since I really used XFree86 and I honestly don't remember if DPMS ever worked with the second head. I don't have a second monitor to test right now. Thanks for your tries and your insight. I will try to hunt these bugs when exams are over. In the meantime let me know if you come up with any patches and I can test them out. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Dec 10, 2003 at 09:03:34AM +0200, Ville Syrjälä wrote: On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote: Thanks for the insight. Is this already something that has been extensively looked at without success, or would it be worth my time to dig into the code and try to find the cause? I've thought about it, but afraid that I will just hit a brick wall someone else already ran into with it. ;) I've attached a patch that should hopefully fix this problem. The render code just forgot to reset the multi texturing registers. I've not actually tested the patch but I don't see anything else wrong with the code... Cool! Is it possible to build the driver modules separately from the XFree86 world, and if so, can you point me at some instructions on how to accomplish that? Is there anywhere I can get a G400 databook for reference, or is that not publicly available? They're not available anymore :( It's a real shame since they seemed to be quite friendly towards open source developers at one point. I can almost understand that they don't want to release any parhelia docs but I don't understand why they stopped giving out the older docs... Must be some new management over there... *sigh* -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
card every six months comes out. It's really just a cycle of control; it makes more sense economically to control people than to give them the information they would need to compete with you on support. (Or to create a cloned product) In my opinion, open hardware is the only solution. We can chase proprietary vendors till we all turn blue, but in the end, they dictate the terms under which their hardware will remain viable for use. I wish that would change, but the trends seem to be going quickly away from openness in the graphics card market, with no sign of reversal. That's driven by demand after all -- people want whiz-bang features, they don't want openness. The few who do want openness are ignored because they are perceived to be too costly to appease. In an open software architecture like the DRI, we should do our best to support proprietary vendors when they give us the means to do so, but all the pissing and moaning about what they will and won't do should go either to /dev/null or, more productively, towards opencores.org and a fully open windowing accelerator and programmable 3D graphics pipeline core. The technology is there, it just needs the mindshare and people's willingness to embrace it. Imagine, an FPGA on an AGP card... upgradable when you feel like it, and with every internal working available for your perusal. Need a faster board, pop out the FPGA with a new model. Need more features, upload a new version of the core. If that prospect doesn't make you tingle, I don't know what would! -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Dec 10, 2003 at 12:25:36PM -0600, Ryan Underwood wrote: In an open software architecture like the DRI, we should do our best to support proprietary vendors when they give us the means to do so, but all the pissing and moaning about what they will and won't do should go either to /dev/null or, more productively, towards opencores.org and a fully open windowing accelerator and programmable 3D graphics pipeline core. I forgot one other place the pissing and moaning can go to: the sales department of all the vendors *except* the one you either are about to buy a new graphics card from, or have just bought one from. Hopefully letting them know that their silliness is hitting them in the bankbook might cause them to mention such things as Linux to managers and shareholders, which might give those the crazy idea that allocating more resources towards providing better support for open source developers just might help them sell more video cards in the end. Lots of 'might' in that paragraph.. well, it doesn't cost much to fire off an email or make a phone call anyhow. Perhaps consider it like playing the lottery. $1 here, $1 there doesn't hurt anybody. The difference in this lottery is that if anyone wins, we all win. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[Dri-devel] MGA font corruption revisited - now reproducible
Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
Thanks for the insight. Is this already something that has been extensively looked at without success, or would it be worth my time to dig into the code and try to find the cause? I've thought about it, but afraid that I will just hit a brick wall someone else already ran into with it. ;) Is there anywhere I can get a G400 databook for reference, or is that not publicly available? On Tue, Dec 09, 2003 at 07:55:20AM -0800, Alex Deucher wrote: renderaccel. the reason for the curruption is that both the 2d driver and the 3d driver are using the 3d engine. since they are not keeping state (render accel my write on 3d textures and vice versa, etc.), games will corrupt fonts and vice versa. Unfortunately it's a tough problem to solve. I don't recall how you turn off render accel on mga, you can probably find that on google. turning it off should solve the problem since render (used for AA fonts) will use teh software paths instead. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri
Re: [Dri-devel] the state of Parhelia on FreeBSD
A small note, if you contact Matrox about adding features to the driver or open sourcing it, the question needs to go to Sales. Support ignores any inquiries about added features and redirect the questioner to sales instead. (They contend that their job is to support only what has been released.) Furthermore, developer relations ignores any questions about the Parhelia period. :( On Fri, Nov 14, 2003 at 09:53:54AM -0800, Alex Deucher wrote: while it might be possible to add support for freebsd to the apparently opensource kernel module, adding support for unsupported cards to the 2D/3D drivers is impossible since it is a binary only driver! Ask matrox to add support. that's your only option right now. Alex -- Ryan Underwood, [EMAIL PROTECTED] --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA G550 w/ kernel mga module version 3.1.0 hard lock
Hey, On Fri, Sep 26, 2003 at 07:37:56AM -0400, Malcolm Mallardi wrote: I resolved this issue yesterday after sending the first mail. Definitely an intentional breakage. Now using the build from yesterday 09/25/03 The OpenGL mouse issue, and console switching issues with kernel module 3.1.0 still exist. Just to let you know, I have a G400 MAX that I use in dualhead (non-merged), and I share the cursor issue with you, but switching from X to VC and back works no problem. So perhaps that issue is isolated to the G550? I use the MGA framebuffer driver though, so maybe things are different e.g. if you are using a VGA text mode on console. -- Ryan Underwood, nemesis at icequake.net, icq=10317253 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] what's the meaning of 'Graphics Aperture' in AGP?
Hi, On Wed, Sep 17, 2003 at 03:30:09PM +0800, Tao, Qian ( IES) wrote: I am a newbee in dri. Now i am reading agp source code in linux kernel. I am not clear about 'Graphics Aperture' I download AGP spec 2.0,but it don't say a word about it. what's the relationship between the aperture with graphics memory? thanks for any comment or replyBest Regards, IIRC, the aperture is the largest region of system memory that may be used for AGP DIME texture storage. (for Execute Mode) So if you set the aperture to 16MB, no more than 16MB of system memory can be used as non-local texture memory for the AGP card. -- Ryan Underwood, nemesis at icequake.net, icq=10317253 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
