I had a look at x.org's sunffb and all they did is to rewrite
ffb_accel.c to use XAA and add a hardware-accelerated alpha-blending
function ( plus accompanying changes in ffb_driver.c to load relevant
modules and a few more or less trivial ones in other files ). Now I have
something that
On Tue, 2005-10-04 at 14:38 -0700, Mark Vojkovich wrote:
Whoops, I'm wrong. It turns out it's not in the EDID. For
desktop systems this is set in the control panel. For laptops,
the driver keeps a list of known panels. The iMac is essentially
a laptop.
Well, it actually _could_ be in
The iMac looks very laptop-like so I'm not surprised it has a
6 bit panel. It might be in the EDID. I'm not sure how else
software would be able to know.
I'll try to find somebody with access to the appropriate VESA specs to
find out then. The other way to know is what Apple does in OS X
On Sun, 2005-10-02 at 18:32 -0700, Mark Vojkovich wrote:
FPDither takes 8 bit output and dithers down to 6 bit. It
will improve the quality on 6 bit panels and degrade it on 8
bit panels. Nearly all desktop panels are 8 bit (only very cheap
or very old ones are not). Most laptop panels
Hi David !
On looking through the fbdev drivers in the Linux kernel source, I see
very few cases where license notices from XFree86 driver source are
included. This means that either the license for these drivers has no
impact on the work you are talking about (making what you have written
The Author ?
This is open source code; there may be 27 authors of the relevant file.
In XFree86 code I wouldn't know how to find the author of a file without
looking at that file. My {limited ,mis}understanding of clean room coding
makes me wary of reading any source unless I know that its
latest CVS build (by myself) as of yesterday (4.3.99...)
When did you try exactly ? I've seen more fixes for TMDS getting
in the CVS recently. I'm not sure what's up here, definitely not
something the doc explains. I suspect it's the path of pixel
data from the framebuffer to the TMDS
On Fri, 2003-06-13 at 00:10, Alex Deucher wrote:
there are alot of issues with dualhead and LCDs on PPC. I believe the
fix is to use fbdev, but I'm not sure anyone has gotten dualhead to
work yet. check the archives from last month.
I had it working on the M6 a while ago, I haven't yet tried
On Fri, 2003-06-13 at 17:08, Andreakis, Dean (MED) wrote:
Given this result I tried comparing the sections of code in the kernel
fbdev driver and the XF86 radeon driver that sets up the PLL and there
was just a few minor diff's in the default min/max values. I went ahead
and changed these to
this further down if
possible ...
Cheers,
Simon
--
Benjamin Herrenschmidt [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
It *may* not always be required. There have been GLX extensions in the
past (see my first message in this thread) that worked that way.
However, as we discussed earlier, this doesn't seem to work so well with
MPEG video files. The main problem being that you don't get the frames
exactly
On Mon, 2003-03-10 at 16:46, Benjamin Herrenschmidt wrote:
The problem is that this IVAD cirtuit also controls the geometry
and brightness of the screen, and should be configured properly after
each mode setting. It has a EEPROM containing geometry settings for
each of the supported modes
Hi !
I have some need that I'm not sure how to implement cleanly.
The problem is related to machines like the CRT iMacs (or eMacs). Those
machines have a built-in monitor that is driven by a weird chip called
IVAD (or VCP on older models) that is available via a motherboard
i2c bus (not the
On Sat, 2003-03-01 at 03:18, Mark Vojkovich wrote:
Hmmm. I've never tried it on a PowerBook. I guess I will have
to see if I can borrow one from around here to play with. Unfortunately,
that means it's unlikely to be fixed in 4.3 (I recall having a difficult
time with Linux PPC
14 matches
Mail list logo
