| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Signed-off-by: Priit Laes <plaes@plaes.org>
|
|
The LX is a bit odd in that the palette can be used for gamma correction
of graphics data, or video data, but not both at the same time.
Right now, during X startup, X sets gamma correction (but without any
actual correction) causing the Geode driver to start using the palette
for graphics gamma correction. (this is just momentary)
Later on during startup, vg_set_custom_mode() switches to using the
palette for video gamma correction, and this is the end result.
If you later use xrandr to change the gamma, the palette starts being used
for graphics again.
If you VT switch, vg_set_custom_mode (momentarily) starts using the palette
for video, but then X jumps in with a gamma callback causing it to be used
for graphics again.
End result: no user visible bug, but this is inconsistent.
As there is no exposed mechanism for changing video gamma I suggest
we just drop that bit from vg_set_custom_mode(). Then the inconsistency
goes away.
Downside: this now becomes dependent on X setting gamma during startup.
I don't know when this was introduced but I think it is recent.
Aditionally, I think I found a (harmless) bug in
df_set_video_palette_entry, it doesn't do what the comments say.
|
|
Signed-off-by: Priit Laes <plaes@plaes.org>
|
|
NOTE: the eCafe EC-800's panel doesn't support a higher refresh rate.
|
|
Signed-off-by: Frank Huang<frankr.huang@amd.com>
|
|
|
|
This reverts commit fab58e111b6655602b4f739260a01247ff478f35.
|
|
Signed-off-by: Frank Huang<frankr.huang@amd.com>
|
|
*Change the entry of 1024x600 from 3 to 7(That will not affect the entries from
3 to 6). And BIOS should set the VG_FP_TYPE bit[5:3] to 7.
*Use 1024x600@80 instead of 1024x600@60 parameters to support more 4:3 resolutions
Signed-off-by: Frank Huang<frankr.huang@amd.com>
|
|
Putting a frozen DCON to sleep (as happens during regular boot of the XO)
will cause the frozen image to be corrupted.
Change the behaviour to only sleep when the DCON is not frozen.
http://dev.laptop.org/ticket/10196
|
|
I don't know why X can't do this itself, but when no get_crtc method is
provided, X decides that it doesn't know the CRTC of the output and
decides to reset the mode completely (causing display powerdown, resulting
in an uncomfortable visual interruption to OLPC's boot process).
|
|
*Del for deduct the probable size of a video overlay.
*Use exaOffscreenAlloc allocate the video overlay.
*Use exaOffscreenAlloc allocate the offscreen surface.
*XV-video data has to be allocate in offscreen memory range.
Signed-off-by: Hunk Cui <Hunk.Cui@amd.com>
|
|
*Users can not get 1024x600 by default when using panel without xorg.conf.
Add this screen resolution to the panel_modes table to support it by default.
*Users who are using VGA will get this resolution by the monitor EDID. No
code is needed
*Use gtf tool to get the parameters
*Ubuntu bugzilla #433142
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
*change from 1028 to 1280
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
*mode validation(lx_output_mode_valid) in this driver should return MODE_OK for
all modes filtered out by previous process in this function. Otherwise, new
modelines(conf_modes) will be pruned by Xserver function Xf86PruneInvalidModes.
The result is that the user can not set arbitrary resolutions. We comply with
the code of ATI&&Intel mode_valid function to do this.
*For modes that cannot be supported by the geode driver, it is better to give
the specific MODE_XXX(such as MODE_CLOCK_RANGE) instead of MODE_BAD.
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
*Modify rotation pitch value with crtc_mode_set.
*Use own wrapper to allocate a pixmap for wrapping a bo.
*Ubuntu Bugzilla #377929
*Debian Bugzilla #512020
Signed-off-by: Hunk Cui <Hunk.Cui@amd.com>
|
|
|
|
This is pretty clearly a bug. This should fix it (after all, that
check is merely to see if the panel is a DCON; we don't care at
all about the panel bit). This also adds an extra parenthesis in
the following if() statement for clarity.
I'm resisting the temptation to change GeodeRec's Output member to
an unsigned long (for now). Bitfields should really be unsigned.
Signed-off-by: Andres Salomon <dilinger@queued.net>
|
|
* Replace the deprecated functions with new ones
Refer to "/xserver/include/os.h"
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
We are pleased to announce this maintenance release of xf86-video-geode.
It features a plethora of bug fixes, a few documentation updates and one
performance enhancement.
This release also marks the return of AMD to the development team.
Please read the content of NEWS for more details.
|
|
*Correct the entry for PictOpIn, PictOpOut, PictOpOverReverse
*Some code format adjustment
*Delete the maskflag(temp variable)
*Change the code to make the black region(More reasonable than change
op from PictOpSrc to PictOpClear)
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
*Correct the entry for PictOpOverReverse and PictOpInReverse
*Correct the channel reverse use, delete direction use
*Add a function lx_composite_all_black to generate a all zero vectors
including alpha
*Modify some comments
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
Fixes bug #27725
Breakage from commit 38e86827
|
|
|
|
|
|
|
|
|
|
*Correct the entry for PictOutReverse
*Outside the source picture, the pixels should be all zero when doing
the PictOpOutReverse rendering with Dst
*Rename the function name of pict_a8 to add_a8
*Rename the function name of opover to two_pass
*Fix the bug in KDE dolphin file browser
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
*Add a PICT_a8 entry in the format we support
*Use Mart's workaround patch to give geode PictOpAdd correct pSrc
and pDst format
*Add a function lx_composite_onepass_pict_a8 to handle the PictOpAdd
for glyph rendering
*Performance for "x11perf" command under Fedora 12
Past Now
-aa10text 4660/sec 53300/sec
-aa24text 2740/sec 16200/sec
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
*Correct the type of LXAllocShadow from Bool to static Bool.
Signed-off-by: Hunk Cui <Hunk.Cui@amd.com>
|
|
This reverts commit ebe43da32226eb7bc3ef758c43eff85ac8b8baef as Frank
pointed out that I mistakenly committed an outdated version of this.
|
|
*Correct the type from "Q_WORD" to "QQ_WORD" in panel.c
*Correct the tyep from "char" to "const char" in z4l.c
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
*Add a PICT_a8 entry in the format we support
*Use Mart's workaround patch to give geode PictOpAdd correct pSrc and pDst
format
*Add a function lx_composite_onepass_pict_a8 to handle the PictOpAdd for
glyph rendering
*Performance for "x11perf -aa10text" has been improved from 4200/s to 47400/s
on Fedora12
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
*Del for deduct the probable size of a shadow buffer.
*Use exaOffscreenAlloc allocate the shadow buffer.
*Rotateeddata has to be allocate in offscreen memory range.
*Ubuntu Bugzilla #377929
Signed-off-by: Hunk Cui <Hunk.Cui@amd.com>
|
|
*Modify integrated palette RAM for gamma-correction of the data stream
*Let Graphic data passes through the Gamma Correction RAM
*Special for Screensaver Operation
*FreeDesktop Bugzilla #27853
Signed-off-by: Hunk Cui <Hunk.Cui@amd.com>
|
|
This is patch 4 final this week.
This one has fixed several bugs below:
1)google chrome hang
2)Some website using repeat for source picture with PictOpSrc. To sum up, right now this patch has gracefully solved the Nautilus bug and some special rendering under PictOpSrc and PictOpOver I will describe all special conditions I met
Websites for test before and after this patch:
1)http://daduke.org (greater srcX and srcY)
2)http://bjdns2.cncmax.cn (negative srcX and srcY)
From: Frank Huang <frankr.huang@amd.com>
*When the srcX or srcY is greater than source width or source height
(or negative),the driver should do the correct region to render. Add a
function lx_composite_onepass_special to handle this. The source start
point should be calculated by a modulus operation.
*If the opeartion is with a shifted position src, then adjust the
operation region based on the operations src width and height
parameters. The rotation condition should be excluded. This part still
need investigation
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
Fix the PictOpOver operation
*Fix the PictOpOver blend_ops struct. The PictOpOver operation is
Src + (1-a) * Dest. So change from CIMGP_ALPHA_A_PLUS_BETA_B to
CIMGP_A_PLUS_BETA_B. And add one pass operation to do the
Src * (alpha of Mask) if there is a mask
*Convert the source format in lx_prepare_composite if it is not
ARGB32 when doing the first pass
*Add a function lx_do_composite_mask_opover to handle the PictOpOver
operation, the first pass is to do the Src * (alpha of Mask), the
second pass is to do the Src + (1-a) * Dest.
*Due to our off-screen buffer is only 256KB, so split big Mask region
into several small region(256KB) to do the rendering.
*Progressbar, scrollbar and button display well with this patch
*See Free Desktop Bugzilla #28352
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
Fix the PictOpSrc rendering
*Add the maskrepeat variabel to record mask picture's repeat attribute
*Add the maskflag to record the exaScratch.type when it is COMP_TYPE_MASK
*Use the PictOpClear to make other non-blending region(out of src or mask)
to be black if the op is PictOpSrc or PictOpClear
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
not zero
Put the one pixel rendering work back to the server to handle if the pMsk is not zero
*exaScratch.srcWidth and exaScratch.srcHeight are used to reocrd
mask's width and mask's height if mask is not zero. So the one pixel
source's width and height are missing in lx_do_composite. So we must
fallback. Otherwise, bigger region will be wrongly rendered.
Signed-off-by: Frank Huang <frankr.huang@amd.com>
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=29391
LXCopyFromSys currently is hardcoded to operate on 16bpp data.
And indeed, when working with packed data (e.g. YUY2), this is the case.
However, it is also used from LXCopyPlanar to copy the planes of I420
images. In this case, it is on an 8bpp input plane.
Running at 16bpp causes twice as much data to be copied, and ultimately
causes a buffer overflow leading to crashes such as
http://dev.laptop.org/ticket/10260
Fix this by deriving the BPP from the input image parameters.
|
|
|
|
If the opeartion is with a shifted position mask, then adjust the
operation region based on the operations mask width and height
parameters(instead of clipping based on source width/height)
Signed-off-by: Frank Huang <frankr.huang@amd.com>
Acked-by: Mart Raudsepp <leio@gentoo.org>
|
|
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
This allows the driver to be built against either the old or new
DevPrivate API.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
|
|
RENDER extension version 0.10 added support for doing server-side
gradients and solid fills, which we were not handling at all.
cairo-1.9 started making use of server-side gradients, and we are
crashing on those, as the source pixmap (pxSrc in lx_prepare_composite)
doesn't have a drawable in this case, and we were not expecting such
a possibility.
So, as the first measure, fallback (three years late) all server-side
gradients and solid fills instead of crashing, until we have no code
that tries to accelerate cases of these or aren't sure if we even
can accelerate any cases.
pSourcePict member was added to xserver in 2005, so no compatibility
wrapping needed.
Signed-off-by: Mart Raudsepp <leio@gentoo.org>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
Bring all the "return FALSE" condition forward from lx_prepare_composite
to lx_check_composite. The Xserver will handle this condition. See more
on Freedesktop Bugzilla #27243
Signed-off-by: Frank Huang <frankr.huang@amd.com>
Acked-by: Mart Raudsepp <leio@gentoo.org>
|
|
|
