Hello. I am currently writing a display driver (UMS, not framebuffer or KMS) for a very ancient card, the Oak Spitfire OTI64111. This weekend I tried this code with the Fedora 14 xorg server (I previously wrote most of the code on Fedora 12). When I run
the driver as the only card for the xorg
After writing a somewhat functional xorg driver for the OAK Spitfire
OTI64111 video card, I am trying to modify the driver to support the
OTI64107 video card, which I have plugged in my test machine. The first
strange thing that I notice about this card is that it reports a MMIO
region that is
Maybe this is not the proper list for this question. If this is so,
please indicate the proper place for this question.
I have a Fedora 12 x86_64 system, with an intel video chipset. This
system uses a Princeton flat panel connected through a standard VGA
cable. This flat panel is odd since it
After a lot of googling, I found a PDF file of a photocopy of a
datasheet for the OAK 64107 graphics chipset, which seems very similar
to the 64111 that I have. With this, the OAK.TXT file from the VGADOC
zipfile floating around the net, and examination of register settings on
the card itself,
Two weeks ago, my home computer with the integrated ProSavageDDR video
chipset died on me. After several attempts to diagnose the problem, it
seems that the mainboard itself is damaged. So I built myself a new
machine with an Intel i915 video chipset. Therefore I am no longer able
to develop
The DRI code attempts to use XAAGetCopyROP without checking whether XAA
or EXA is in effect. This results in the server crashing with an
undefined-symbol error when enabling EXA, then starting glxgears under
GNOME/Metacity and attempting to drag the glxgears window.
The EXA code happens to
The Linux kernel version 2.6.29-rc7 introduced a regression that makes a
mmap2() call on /dev/dri/card0 fail with EAGAIN on Savage chipsets
(don't know about other chipsets yet). I have not yet bisected it or
filed a bug for it (since I want to check 2.6.29-rc8 for this bug), but
this in turn
I am checking out what happens when I disable kernel modesetting for a
radeon chipset (Xpress 200M RC410) with the xorg-x11-drv-ati package
from updates-testing in Fedora 10. So far I have seen that the driver
refuses to enable DRI support, as it claims that 64Mb is not enough
memory. I added
Alex Deucher escribió:
On Thu, Feb 12, 2009 at 11:59 AM, Alex Villacís Lasso
a_villa...@palosanto.com wrote:
As you can see, my primary (and only) screen is using a resolution of
1440x1080, the maximum one it supports. But the DRI calculation is being
done on 3520 x 1600
Alan Coopersmith escribió:
Alex Villacís Lasso wrote:
kbd.c:154: error: 'XKB_DFLT_RULES' undeclared here (not in a function)
This is from a recent git pulled this morning. I am pulling the changes
from the last few hours, in the hope this is fixed by compiling an
updated proto
Alan Coopersmith escribió:
Alex Villacís Lasso wrote:
Alan Coopersmith escribió:
Alex Villacís Lasso wrote:
kbd.c:154: error: 'XKB_DFLT_RULES' undeclared here (not in a function)
This is from a recent git pulled this morning. I am pulling the changes
from the last
Tiago Vignatti escribió:
Hi,
Alex Villacís Lasso escreveu:
Another question I have is this: as far as I understand, PCI video
cards have to run the POST (or do an equivalent operation) in order
to execute the chipset-specific hocus-pocus that enables legacy vga
port access (0x3c0
gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wpointer-arith -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs
-fno-strict-aliasing -Wbad-function-cast -Wold-style-definition
-Wdeclaration-after-statement -fvisibility=hidden
-I/home/alex/xserver/include/xorg
A few days ago, I posted a patch for bug #19337, which affects the
savage driver with current xserver git, and possibly many other
non-xrandr 1.2 enabled drivers. I think this patch needs to be reviewed
and possibly merged, because it fixes an annoying crashing regression
with users not
Alex Deucher escribió:
On Fri, Jan 16, 2009 at 3:21 PM, Alex Villacís Lasso
a_villa...@palosanto.com wrote:
Alex Deucher escribió:
From what I glean from the traces, it seems that using VESA to start up
the primary Savage chipset works correctly. However, when trying
I am trying to enable I/O port tracing on current xserver head in my
home machine (Linux 2.6.28 on x86 Pentium 4 32-bits, ProSavageDDR-K as
primary card, Oak OTI64111 as secondary card) in order to learn about
the register initialization for the video BIOS of both the Savage and
the Oak
Alex Deucher escribió:
On Thu, Jan 15, 2009 at 3:10 PM, Alex Villacís Lasso
a_villa...@palosanto.com wrote:
I am trying to enable I/O port tracing on current xserver head in my home
machine (Linux 2.6.28 on x86 Pentium 4 32-bits, ProSavageDDR-K as primary
card, Oak OTI64111 as secondary
With the latest git for xserver and the latest git for savage, an
attempt to start up crashes the server unless this patch is applied. It
seems that an explicit xf86CrtcConfigInit() is now required in the
PreInit stage of the driver setup. I found via valgrind that the absence
of this call
Alex Deucher escribió:
On Tue, Jan 13, 2009 at 11:36 AM, Alex Villacís Lasso
a_villa...@palosanto.com wrote:
With the latest git for xserver and the latest git for savage, an attempt to
start up crashes the server unless this patch is applied. It seems that an
explicit xf86CrtcConfigInit
Alex Villacís Lasso escribió:
Optimization. Saves one compare per DWORD for common case where BCI
queue has ample space for bitmap data.
Changelog:
* EXA: use memcpy instead of loop for UploadToScreen operation
This flag was added by me in a patch, but forgot to update the man page.
This patch adds such update.
Changelog:
Document existence of IgnoreEDID option.
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
From c67186bbb0070f53f2e801a71967f5482ae76789 Mon Sep 17 00:00:00 2001
This is a preparation for the next patch (placing XVideo YV12 data in
AGP memory). Currently a single buffer is allocated for YV12 planar data
and the YUY2 packed data that is the true format that the card can
display. This patch splits the buffers into two separate allocations,
and adds the
This patch adds the capability to place YV12 data in AGP memory while it
is being converted to packed YUY2. The single most expensive operation
in XVideo rendering on savage (on current implementation) is the upload
to the framebuffer. By placing YV12 data in an AGP buffer, the CPU saves
Optimization. Saves one compare per DWORD for common case where BCI
queue has ample space for bitmap data.
Changelog:
* EXA: use memcpy instead of loop for UploadToScreen operation
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
From
Resending as previous attempt complains attachments are too big.
All of the following applies to the stock linux 2.6 kernel from a fresh
installation of Fedora 10.
I have been looking into the int10 hang when initializing the BIOS of a
secondary card. This is what I found:
- The function
Timothy S. Nelson escribió:
Hi all. I'm upgrading from Fedora 6 to Fedora 10. I did a clean
install of Fedora 10 and then, as the default X config didn't work, I
copied across my old xorg.conf file. Naturally I had to comment out a
few lines in that file.
Now a word on my setup. I
In the reference documents for the savage video card, there is an
operation called a mastered image transfer, which looks like an
accelerated pixmap upload into the framebuffer. This operation
references registers with bit flags to select between framebuffer
memory and system memory. However,
Good news! My machine rose itself from the dead while salvaging its
memory chips, so now I can continue tinkering with the savage driver.
Since a while ago, I am trying to write an EXA composite acceleration
implementation for savage. I have gotten to the point that I can pipe a
few vertices
A few days ago I reported a bug
(https://bugs.freedesktop.org/show_bug.cgi?id=18378) about XV
colorkeying breaking when Metacity compositing is enabled. Michel Dänzer
was kind enough to explain the root issue to me, and I prepared a patch,
here attached. Please review.
--
perl -e
Recently I dug up a very old graphics card, an Oak Spitfire OTI-64111 by
Oak Technologies. After looking up information for it in Google, I found
that there is no specific driver for xorg (although there are plenty of
mirrors for windows drivers). I want to familiarize myself with graphics
30 matches
Mail list logo
