Age | Commit message (Collapse) | Author | Files | Lines |
|
This file is provided by libdrm. The correct path to it should be
provided by the libdrm pkgconfig file already.
The path has changed from <prefix>/include/drm to <prefix>/include/libdrm
recently.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
|
|
Signed-off-by: Egbert Eich <eich@freedesktop.org>
|
|
Now we might get called not only for changing frame or clipping,
but also for changing modes. Handle this accordingly.
Signed-off-by: Luc Verhaegen <libv@skynet.be>
|
|
These symbols are marked deprecated in newer X versions.
Signed-off-by: Luc Verhaegen <libv@skynet.be>
|
|
Reported by Kanotix's Jörg Schirottke.
|
|
Reported by Lluís Batlle i Rossell.
|
|
|
|
Fix issues pointed out by NixOS's Lluís Batlle i Rossell:
* xvmc has its own .pc file and thus its own header location.
* dpms headers are part of xextproto and not xproto and thus
need a different header .pc location as well.
Further issues fixed:
* xvmc build depends on DRI (for no good reason).
* fix variable status uninitialized warnings on older X.
|
|
* Full autoconf checking of available infrastructure.
* Work around broken vldXvMC.h headers that useless include
include XvMClib.h.
* Use the new dixLookupResourceByType call when available.
* remove useless pc file for libXvMCunichrome, no-one will build against
this lib anyway.
* Fix up debian build system for the new xvmc dependency (if you do not
want to depend on this debian package, build manually).
* Set library version properly.
* Fake XvMCDrawable is not a pointer.
* Bump XVMCE proto version to 0.1. From now on we need to track this.
* Build driver side xvmc support conditionally, but always build mpeg
handling code for preprocessing simplicity.
|
|
|
|
|
|
|
|
|
|
|
|
Removes some noise in the log, but does not remove the bug i am
seeing with xine (old mpeg sizes passed when going back to YV12).
|
|
There's a lot of cpu cycles to be gained by avoid the usleep system call.
|
|
|
|
Serverside sync everything on its own anyway. Ain't that nice.
|
|
|
|
|
|
There is little to no correlation between the subpicture support
in this hardware and the API. Also, the xine module is very very
badly implemented. So drop subpictures completely for now, when
there is a winner in the new APIs, i will port my working hw level
code to that.
Add an xorg.conf option which enables us to fool the xine xxmc
module to start by halfarsedly claiming subpictures.
|
|
The API for subpictures is horrible. And quite amazingly so..
|
|
|
|
Next up, subpicture support.
|
|
|
|
|
|
|
|
Clean up the interface, bail out of SliceInit and SlicePut before touching
the hw. Buffer allocation and handling seems ok now.
Next up, having Xv display empty Mpeg allocated buffers.
|
|
I just made it build and did some boilerplate things. Next up, i will
try to hook it to actual calls.
|
|
Next up, attaching hw code!
|
|
|
|
|
|
|
|
Qmatrix is part of the newly created X protocol.
Surface and context creation/destruction, XID based, is using plain old
XvMC.
Verbosity was increased on both sides of the thing, to clearly track
and verify the workings of the above code.
|
|
|
|
Add some initial code for the _further_ X extension.
|
|
|
|
|
|
|
|
xf86MatchDevice returns one then, but the pointer is still nulled. Accessing
the first element of NULL then leads to fun.
Also fix up the DoConfigure message of preinit (where we stop PreInit from
being abused for monitor configuring).
|
|
|
|
|
|
* Improve debug output by showing multiplier, divider, postdivider.
* Change logic to prefer lower multiplier/divider combinations when
the result is the same.
* Tighten up layout and structure.
|
|
* Add FIFOSet functions.
* Use VT3230 PLL calculation, close to this, but less steep and
lower.
* Leave the rest of CRTC testing for this device as a TODO.
|
|
SR1A.1 is supposed to be MMIO enable, but when the device is
accessed like a plain VGA device (whether this is through
register space or memory, i do not know yet), the VT1122 hangs
hard. VT1122 seems happy without this change though, maybe find
out what hardware really needs this.
|
|
Plus, get rid of the VT3225 comment that was still left over.
|
|
* Add FIFOSet functions.
* Change VT3157 PLL routines to calculate the limit for VT3230,
as this is the steepest and most left limit of VT3157, VT3230,
VT3343 and VT3371; but all are very close.
* Leave the rest of CRTC testing for this device as a TODO.
|
|
The one with _full_ coreboot support!!!
|
|
* Add FIFOSet functions.
* Use VT3157 PLL routine; it's close enough.
* Keep the rest of the CRTC testing as a TODO for now.
|
|
Got (semi-deliberately) broken by cca480fe.
|