Start adding the infrastructure to disable direct hardware access if X
is being run under a system compositor (aka "hosted").
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When printing out the list of supported chipsets, remove the (many
times) repeated names as they are very confusing and obscure the product
name you may be searching for.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For these parts we do not yet known the correct marketing name, so
replace our use of the codename with the generic term.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we recognise the PCI-ID but do not have a marketing name for it, it
means we are deliberating ignoring it - presumably because it is an
engineering sample. In this case, we do not want to print out a warning
into the logfile so replace the "Unknown chipset" with some info
about the future product.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than duplicating the information we already use in the kernel, we
can reuse the pci-id tables so long as we apply a little fuzz.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently we leak the fd should we open the device node and decide that
is not a GEM/KMS kernel driver. The simplest way to perform the cleanup
upon failure is to move the checking for GEM/KMS into the device open
routine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Merge the device open in the main driver with the probing so that we can
open the path explicitly passed in by the PlatformProbe and keep that fd
around for the main driver and so avoid a later search.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we find out more of the final product names for Haswell chipsets, we
need to update the user visible identification strings.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Start filling in the names for the parts that have been announced, the
Iris branded Haswell GT3 parts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As Chris mentioned there is a tendency for us to find out more
PCI IDs only when users report. So let's add all new reserved Haswell IDs.
I didn't have better names for this reserved ids and didn't want to use rsvd1
and rsvd2 groups, so I decided to use "B" and "E" that stands for the last
id digit.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
When publishing first HSW ids we weren't allowed to use "GT3" codname.
But this is the correct codname and Mesa is using it already.
So to avoid people getting confused why in Mesa it is called GT3 and here
it is called GT2_PLUS let's fix this name in a standard and correct way.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
There is a tendency for a product to ship based on a 'reserved' PCI-ID
prior to us being notified about it. In other words, the first we find
out about such a product is when customers start complaining about their
shiny new hardware not being supported...
References: https://bugs.freedesktop.org/show_bug.cgi?id=63701
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Do not rely on a fully populated set of CRTCs, but merely note that the
GETRESOURCES ioctl returns an error if KMS is not enabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the kernel has the module, but the KMS module option is not enabled,
we cannot function. So after checking to see if the i915.ko is bound,
then querying whether it provides any KMS resources. If it has no CRTCs
attached, then we need to failover to the VESA/fbdev drivers. Note that
this should have been detected by drmCheckModesettingSupported()
References: https://bugs.freedesktop.org/show_bug.cgi?id=60987
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once upon a time this was used to hide a compiler warning about a
pointer mismatch, now the compiler still warns about the cast, making
the indirect moot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow --enable-ums-only as a counter-option to --enable-kms-only in case
the distribution wishes to enable a non-root KMS driver but also offer
a separate UMS driver for i81x.
On the second pass, use "--enable-ums-only --disable-uxa --disable-sna"
to get the trimmed down unaccelerated i810 support.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Thanks to Adam Jackson for pointing me towards drmGetVersion() and
Julien Cristau for saying "Yuck!"
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This fixes an issue with us claiming Poulsbo and friends even though we
do not speak their language.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I think the likelihood of a new product being launched based on a 8xx
design is remote enough not to worry about.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>