| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
RandR outputs listed in Option "RROutputOrder" (separated with spaces or
commas) will initialized first, and in this order. The Xinerama screen order
is apparently directly reflecting this order.
|
|
|
|
|
|
|
|
This adds the following (immutable) properties to every output, as partially
described for discussion in an randrproto.txt diff on xorg-devel:
RANDR_SIGNAL_FORMAT
Type: string
Range/List: unknown VGA TMDS LVDS FBAS SVideo
YPbPr DisplayPort
Signal format / physical protocol format that is used for the
specified output.
A driver MAY change this property of an output if the
underlying hardware indicates a protocol change (e.g. TV
formats).
RANDR_CONNECTOR_TYPE
Type: string
Range/List: unknown VGA DVI DVI-I DVI-A DVI-D HDMI
internal TV TV-FBAS TV-SVideo TV-YPbPr
TV-SCART TV-C4 DisplayPort
Connector type, as far as known to the driver. Values with
dashes (TV-FBAS) describe more specific versions of the base
values (TV). The former SHOULD be used if the connector is not
capable of producing other signal formats. The later SHOULD be
used if the exact connector is unknown, or the connector is a
multi-format connector that is not described otherwise.
'internal' describes laptop-internal (normally LVDS) displays.
'TV' and 'TV-SCART' with signal format 'VGA' are valid
combinations and describe RGB TV signals.
RANDR_CONNECTOR_NUMBER
Type: int32
Range/List: 0-
Outputs that route their signal to the same connector MUST
have the same connector number. Outputs with the same
connector number MUST route their signal to the same
connector, except if it is 0, which indicates unknown
connectivity. 1 is called the primary connector, 2 the
secondary. 3 is often a TV connector, but that is completely
driver / hardware dependent.
Outputs with the same connector number SHOULD have the same
connector type. Meaning and client behavior for mismatching
connector types is undefined at the moment.
RANDR_OUTPUT_NUMBER
Type: int32
Range/List: 0-
A card may route one internal output to several connectors.
Connectors that are driven by the same output cannot be driven
by different Crtcs and are thus only allowed to be used in
clone mode. The driver SHOULD emit an error message and
continue as gracefully as possible if using different Crtcs for
the same internal output is requested.
Internal outputs are numbered from 1, 0 indicates that output
routing is unknown.
|
|
This one has a rather awkward atombios connector table and requires an id based
workaround.
Thanks to Jerome Glisse.
|
|
Also documented one of the more exotic error messages.
|
|
|
|
|
|
|
|
|
|
Something that cannot be solved with the current RandR model is that multiple
connectors might be attached to the same output. They cannot be driven with
different crtcs then, but RandR sees them as different outputs because of a
missing abstraction layer. This implementation will silently set one crtc or
the other, and maybe even won't warn.
|
|
Create a pci device id based table with electrical values for all
currently known devices with TMDSA. Warn verbosely about unknown devices.
TMDSB now also includes support for the RV530 on the Dell low profile card.
|
|
|
|
|
|
|
|
Called "TMDS B".
No Load Detection possible.
|
|
|
|
|
|
Conflicts:
src/rhd_cursor.c
src/rhd_driver.c
|
|
|
|
The obvious approach to handle everything in rhdRROutputModeSet doesn't
actually work, because this function doesn't get viewport information.
|
|
Nuke the remaining (commented) monitor handling code.
There is no rhdMonitor section filled in in rhdConnector yet. Dunno whether
we will eventually need it.
|
|
|
|
|
|
Also, Output->Crtc is now set in ModeSet() only.
|
|
Also improved other outputs.
|
|
|
|
|
|
A normal "make" run on imake builds will not descend into
utils/conntest/ any more. However, "xmkmf -a" still creates
utils/conntest/Makefile from the Imakefile, so the user can
"cd utils/conntest && make" to build rhd_conntest.
|
|
Consequent separation of source tree dir ($srcdir) and working
dir ($working_dir). Fixes imake and automake in-tree builds.
|
|
If either of those is not found, rhd_conntest is not built.
Affects automake builds only.
|
|
|
|
|
|
This update was found using experimental code which updates
the man page from the rhd_id.c RHDIdentify() output.
|
|
radeonhd handles monitor sections differently, and thus does not cause
these problems, since 2aa53c95a85824f4ed175943acf7f1c37cbe8e8c.
|
|
|
|
|
|
Defines a number of CPP macros with a git commit version message
if source tree is git checkout.
Both radeonhd_drv.so and rhd_conntest print that version message.
Numerous adaptations to git_version.sh and build rules:
* only touch git_version.h if content needs to change
* always define useful GIT_MESSAGE
* add example program using git_version.h
* handle srcdir != builddir
* variable header name and ifndef
|
|
|
|
"make dist" tarballs can now be built with imake.
Build, but do not install rhd_conntest by default (am+imake).
|
|
This is strange... if we set virtualX/virtualY like the intel driver does, we
limit ourself in the future to this maximum size.
The check for this is internally in RandR, no idea why the intel driver
actually works this way...
Even more curious: if we DON'T update virtual, everything seems to work as
expected...
|
|
Also nuked some assert descriptions that are VERY unlikely to happen.
|
|
It's wrong this way anyway.
Also add more precautious crtc handling.
|
|
xf86RandRModeConvert sets mode->name to NULL - which lets our mode validation
horribly fail. Copying the name from crtc->mode. This hopefully is not a
memory leak, as the mode SHOULD be cleaned up.
Modes can now be changed successfully.
|
|
If out-crtc is ever not NULL, it is not necessarily the Crtc that will be
used, so it's better to skip crtc checks altogether...
PLL in Crtc might now not be initialized when dpms is called. Ignore then.
An crtc might already be assigned to an output, only assert for not being
active then.
|
|
|
|
If RandR 1.2 support is not available during compile time, the driver will
fall back to standard old-fashioned modesetting.
|
