This adds the framework for DDX provider support.
v2: as per keithp's suggestion remove the xf86 provider object
and just store it in the toplevel object.
v3: update for new protocol
v4: drop devPrivate, free name
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds the initial provider object and provider property
support to the randr dix code.
v2: destroy provider in screen close
v2.1: fix whitespace
v3: update for latest rev of protocol + renumber after 1.4 tearout.
v4: fix logic issue, thanks Samsagax on irc
v5: keithp's review: fix current_role, fix copyrights, fix master
reporting crtc/outputs.
v6: port to new randr interface, drop all set role bits for now
v7: drop devPrivate in provider, not needed, add BadMatch returns
for NULL SetProviderOffloadSink and SetProviderOutputSource, drop
the old typedef.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This loop needs to count from 7 to 0, not only from 7 to 1.
The current code always skips the modes {1152, 864, 75, 0}, {1280, 1024, 85, 0},
{1400, 1050, 75, 0}, {1600, 1200, 70, 0} and {1920, 1200, 60, 0}.
Signed-off-by: Torsten Kaiser <x11@ariolc.dyndns.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Using -O3 gcc notes that m could reach beyound the end of the EstIIIModes array,
if the last bits of the 11s byte where set.
Fix this, by extending the array to cover all possible bits from est.
https://bugs.freedesktop.org/show_bug.cgi?id=45623
Signed-off-by: Torsten Kaiser <x11@ariolc.dyndns.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This option is to stop the X server adding non-primary devices as
gpu screens.
v2: fix per Keith's suggestion.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This provides add/remove support for platform devices at xfree86 ddx level.
v2: cleanup properly if no driver found.
v3: load the modesetting driver before checking driver list.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds callbacks into the ddx for udev gpu hotplug.
v2: fix some strncmp returns.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just adds the structures and interfaces required for adding/deleteing
gpu screens at the DDX level. The platform probe can pass a new flag
to the driver, so they can call xf86AllocateScreen and pass back the new
gpu screen flag.
It also calls the gpu screens preinit and screeninit routines at
startup.
v2: fix delete screen use after free.
v3: split out pScrn into separate patch
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is in preparation for gpu screens in here, just use
a pScrn pointer to point at the new screen.
suggested by Keith.
v1.1: fix spacing as suggested by Aaron.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch introduces gpu screens into screenInfo. It adds interfaces
for adding and removing gpu screens, along with adding private fixup,
block handler support, and scratch pixmap init.
GPU screens have a myNum that is offset by GPU_SCREEN_OFFSET (256),
this is used for logging etc.
RemoveGPUScreen isn't used until "xfree86: add platform bus hotplug support".
v2: no glyph pictures for GPU screens for now.
v3: introduce MAXGPUSCREENS, fix return value check
v4: fixup myNum when renumbering screens (ajax)
v5: drop cursor privates for now.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is a precursor for reusing this code to init gpu screens.
v2: fixup int check as per Keith's review.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
On Linux in order for future hotplug work, we are required to interface
to udev to detect device creation/removal. In order to try and get
some earlier testing on this, this patch adds the ability to use
udev for device enumeration on Linux.
At startup the list of drm/kms devices is probed and this info is
used to load drivers.
A new driver probing method is introduced that passes the udev
device info to the driver for probing.
The probing integrates with the pci probing code and will fallback
to the pci probe and old school probe functions in turn.
The flags parameter to the probe function will be used later
to provide hotplug and gpu screen flags for the driver to behave
in a different way.
This patch changes the driver ABI, all drivers should at least
be set with a NULL udev probe function after this commit.
v2: rename to platform bus, now with 100% less udev specific,
this version passes config_odev_attribs around which are an array
of id/string pairs, then the udev code can attach the set of attribs
it understands, the OS specific code can attach its attrib, and then
the core/drivers can lookup the required attribs.
also add MATCH_PCI_DEVICES macro.
This version is mainly to address concerns raised by ajax.
v3: Address comments from Peter.
fix whitespace that snuck in.
rework to use a linked list with some core functions that
xf86 wraps.
v4: add free list, fix struct whitespace.
ajax this address most of your issues?
v5: drop probe ifdef, fix logic issue
v6: some overhaul after more testing.
Implement primaryBus for platform devices.
document hotplug.h dev attribs - drop sysname attrib
fix build with udev kms disabled
make probing work like the PCI probe code,
match against bus id if one exists, or primary device.
RFC: add new bus id support "PLAT:syspath". we probably
want to match on this a bit different, or use a different
property maybe. I was mainly wanting this for use with
specifying usb devices in xorg.conf directly, but PLAT:path
could also work I suppose.
v6.1: add missing noop platform function
v7: fix two interactions with pci probing and slot claiming, prevents
pci and platform trying to load two drivers for same slot.
v8: test with zaphod mode on -ati driver, fixup resulting issue
clean up common probe code into another function, change busid
matching to allow dropping end of strings.
v9: fix platform probing logic so it actually works.
v9.1: fix pdev init to NULL properly.
v10: address most of Keith's concerns.
v4 was thanks to Reviewed-by: Adam Jackson <ajax@redhat.com>
v5 was Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes some really ugly code that got mangled by the indenting.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This will permit midispcur to allocate its privates for hotplug outputs
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Instead, only save them for the most recently drawn cursor. This saves
a bunch of storage for idle cursors.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This ensures that only screens using fb will have this space allocated.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Screen-specific privates areas are only allocated for objects related
to the target screen; objects allocated for other screens will not
have the private space reserved. This saves memory in these objects
while also allowing hot-plug screens to have additional private
allocation space beyond what the core screens are using.
Drivers are encouraged to switch to this mechanism as it will reduce
memory usage in multi-GPU environments, but it is only required for
drivers which will be loaded after the server starts, like
modesetting.
Objects providing screen-specific privates *must* be managed by the
screen-specific private API when allocating or initializing privates
so that the per-screen area can be initialized properly.
The objects which support screen-specific privates are:
Windows
Pixmaps
GCs
Pictures
Extending this list to include Colormaps would be possible, but
require slightly more work as the default colormap is created before
all colormap privates are allocated during server startup, and hence
gets a bunch of special treatment.
Of particular note, glyphs are *not* capable of supporting
screen-specific privates as they are global objects, not allocated on
a screen-specific basis, and so each driver must be able to see their
privates within the glyph.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
If the driver supports __DRI2_ROBUSTNESS, then enable
GLX_ARB_create_cotnext_robustness as well. If robustness values are
passed to glXCreateContextAttribsARB and the driver doesn't support
__DRI2_ROBUSTNESS, existing drivers will already generate the correct
error values (so that the correct GLX errors are generated).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The assumtion is that if the underlying provider (e.g., glxdri2.c) doesn't
support this extension, it will generate BadMatch for these flags and
attributes.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Also require that the reset notification for a new context and the other
context in the share group match. There isn't yet any way to specify a
non-default reset notification strategy, but that will come.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch builds on the infrastucture put in place for
GLX_ARB_create_context_profile. If GLX_CONTEXT_ES2_PROFILE_BIT_EXT is
specified and the requested version is 2.0, create a context with the
__DRI_API_GLES2 API.
This change assumes that any DRI2 driver can handle (possibly by saying "no
seeing an API setting other than __DRI_API_OPENGL or __DRI_API_OPENGL_CORE.
This allows enabling the extension any time GLX_ARB_create_context (and
GLX_ARB_create_context_profile) is enabled.
v2: Clean up some comments. Note that our behavior for
GLX_CONTEXT_ES2_PROFILE_BIT_EXT w/version != 2.0 matches NVIDIA's.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Most of the infrastructure was already in place. This just adds:
* Validate values specified with the GLX_CONTEXT_PROFILE_MASK_ARB
attribute.
* Select a DRI2 "api" based on the setting of
GLX_CONTEXT_PROFILE_MASK_ARB.
* Enable GLX_ARB_create_context_profile extension.
This change assumes that any DRI2 driver can handle (possibly by saying "no")
seeing an API setting other than __DRI_API_OPENGL. This allows enabling this
extension any time GLX_ARB_create_context is enabled.
Also, the validation code in __glXDisp_CreateContextAttribsARB is structured
in a very verbose manner (using a switch-statement) to ease the addition of
GLX_EXT_create_context_es2_profile.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The protocol is almost identical to SetClientInfoARB. The only
difference is the GL versions include an extra 4 bytes for the supported
profile.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The server does not want GL extension prototypes. It never links with
anything that could possibly provide implementations of these functions. It
*is* the provide, and it does not provde these symbols. All this does is
create hundreds of warnings like:
incude/GL/glext.h:5570:45: warning: redundant redeclaration of 'glMultTransposeMatrixd' [-Wredundant-decls]
include/GL/gl.h:1940:45: note: previous declaration of 'glMultTransposeMatrixd' was here
I believe this was necessary back before the AIGLX days, but that was a long,
long time ago. The warnings recently showed up with the addition of
-Wredundant-decls to the CWARNFLAGS.
v2: Update the commit message, no code changes.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
LoaderSymbol calls dlsym with RTLD_DEFAULT pseudo handle making it search in
every loaded library. In addition glibc adds NODELETE flag to the library
containing the symbol.
It's used in doLoadModule to locate <modulename>ModuleData symbol, the
module's library gets the flag and is kept in memory even after it is
unloaded.
This patch adds LoaderSymbolFromModule function that looks for symbol only in
library specified by handle. That way the NODELETE flag isn't added.
This glibc behavior doesn't seem to be documented, but even if other
implementations differ, there is no reason to search ModuleData symbol outside
the module's library.
Signed-off-by: Michal Srb <msrb@suse.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
v2: Switch LoaderSymbolFromModule arguments order.
Correct description.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Number of devices is 2 + MAXDEVICES, with index 0 and 1 reserved for
XIAll{Master}Devices. At the current size, PropagateMask would be overrun in
RecalculateDeviceDeliverableEvents().
Found by Coverity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Don't leak if ti->history is NULL.
Found by coverity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
*dev is the condition of the while loop we're in, reset to NULL after
freeing
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The hooks are left for this cycle, we can drop it next cycle once the
drivers that need it (e.g. wacom) have been updated.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
We can ignore the "wasset" argument now since the DIX will keep proper
refcounting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Let the dix be in charge of changing the sigprocmask so we only have one
entity that changes it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This merge includes a minor fixup for '%p' arguments; must cast to
uintptr_t instead of uint64_t as we use -Werror=pointer-to-int-cast
which complains when doing a cast (even explicitly) from a pointer
to an integer of different size.
The input ABI hasn't changed, but input drivers need something to hook on if
they want to log from within signal handlers and the input ABI is the
simplest way of doing so.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Already treated as const anyway by all drivers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This corresponds to XListInputDevice(3)'s "type" field (after being
converted to an Atom). Input drivers use the XI_KEYBOARD and similar
defines, even Wacom which falls out of the common defines uses constant
strings here. The use-case for having this non-const is small.
Input ABI break technically, since we never freed this information anyway it
is not a noticable change.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The function can be called from a fatal signal handler.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The function may be called from a fatal signal handler.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The function may be called from a fatal signal handler.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While we probably don't need to be signal safe here since we will never
return to the normal context, the logging signal context check will
cause unsafe logging to be unhandled. Using signal safe logging here
resolves the issue.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
