summaryrefslogtreecommitdiffstats
path: root/client/x11/platform.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix typo; sampel --> sampleJeremy White2014-01-021-4/+4
| | | | Signed-off-by: Jeremy White <jwhite@codeweavers.com>
* Add support for the Opus codecJeremy White2014-01-021-4/+6
| | | | Signed-off-by: Jeremy White <jwhite@codeweavers.com>
* spicec: disable stencil test with primary fboMarc-André Lureau2013-09-301-1/+1
| | | | | | | The primary buffer doesn't use stencil test. However, this should be explicitely disabled, since the canvas might change stencil state, and this will affect primary stencil buffer, making some of further update operations clipped in unwanted ways.
* spicec: use doublebuffer for openglMarc-André Lureau2013-09-301-1/+1
| | | | | | This visually reduces glitches without noticeable speed difference. It's also the traditionnal way of doing opengl.
* spicec: fix non-doublebuffer drawingMarc-André Lureau2013-09-301-0/+1
| | | | | | | | First, context must set it, then Draw/ReadBuffer must be set to FRONT, and then explicit Flush is needed. This patch is mostly for future reference, it is mostly discarded in following patch using double-buffer.
* Add some more 'noreturn' annotationsDaniel P. Berrange2012-04-251-2/+1
| | | | | | | | Methods which longjump, unconditionally raise an exception, or call _exit() cannot return control to the caller so should be annotated with 'noreturn' Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Add missing struct field initializersDaniel P. Berrange2012-04-251-5/+5
| | | | Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Use the spice-common submoduleMarc-André Lureau2012-03-251-2/+3
| | | | | | | | | | | | | | | | | | This patch will replace the common/ directory with the spice-common project. It is for now a simple project subdirectory shared with spice-gtk, but the goal is to make it a proper library later on. With this change, the spice-server build is broken. The following commits fix the build, and have been seperated to ease the review. v2 - moves all the generated marshallers to spice-common library - don't attempt to fix windows VS build, which should somehow be splitted with spice-common (or built from tarball only to avoid generation tools/libs deps) v3 - uses libspice-common-client - fix a mutex.h inclusion reported by Alon
* Fix various comparison between signed and unsigned integer expressions warningsHans de Goede2012-01-231-6/+6
| | | | | | These turn into errors because of our -Werror use, breaking the build. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Remove epoll headers from client codeDan McGee2012-01-231-1/+0
| | | | | | | There is no more usage of epoll on the client side, so no need to include these header files. Signed-off-by: Dan McGee <dpmcgee@gmail.com>
* Remove trailing whitespace from end of linesDaniel P. Berrange2012-01-131-2/+2
|
* client: add xinerama supportArnon Gilboa2011-11-141-0/+147
| | | | | | | | | | | | | | RHEL-6 Bugzilla: 695323 cherry-picked from qspice commit 003667ac99beeec9b330a07bc3569c59a96d4588 which fixes RHEL-5 541566 with merge of the one line qspice fix to SPICE_REQUIRES: 9f3fe4755f11044a45c4b21148466a997fcbf735 spice: fixed reference to xinerama pkg config file (Xinerama.pc=>xinerama.pc) Author: Yonit Halperin <yhalperi@redhat.com>
* client/x11: reset screen positions in XMonitor::do_restoreChristophe Fergeau2011-10-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | XMonitor::do_restore (called for example when going out of fullscreen) restore the screen resolution to its previous state, but it doesn't take care of repositioning the screen to their previous position, which is one of the advantages of using randr 1.2. Since MultyMonScreen::restore handles all of this for us, just call it to restore the monitor position/resolutions to their previous settings. Before doing any changes, MultyMonScreen::restore checks if there's something to do, so calling it once per monitor won't be an issue, the resolution/position will only be set the first time. This has the side-effect of fixing bug #693431. This bug occurs when closing the client after the client went in and out of fullscreen. MultyMonScreen::~MultyMonScreen calls MultyMonScreen::restore, which decides to change the screen positions since they were lost when going to fullscreen because XMonitor::restore didn't restore the positions. After this change, the positions will be properly restored and MultyMonScreen::restore won't be needlessly called upon client shutdown.
* client/x11: fix mode setting in MultyMonScreen::restoreChristophe Fergeau2011-10-051-7/+1
| | | | | | | | | MultyMonScreen::restore changes the X11 Screen resolution, but it doesn't use MultyMonScreen::set_size. This means MultyMonScreen::_width and MultyMonScreen::_height don't get updated to reflect the new resolution settings, which could cause issues later on. Until now this was safe since the only caller of MultyMonScreen::restore was MultyMonScreen destructor.
* client/x11: fix typos (finde => find)Christophe Fergeau2011-10-051-7/+7
|
* fix bug #692833Marc-André Lureau2011-09-011-1/+7
|
* use Xkb to get keyboard modifier maskChristophe Fergeau2011-08-171-23/+2
| | | | | | | | | | | | | | To be able to enable/disable keyboard leds on X11, we need to query the X server for which mask correspond to which led (NumLock, CapsLock). So far this was done using XKeysymToKeycode and iterating over X modifier mapping. Xkb provides XkbKeysymToModifiers for this purpose, and since we're using Xkb anyway, it makes more sense to use it. At some point, on my Fedora 15 box, XKeysymToKeycode was returning NoSymbol for CapsLock and NumLock leading to spicec not being able to change the keyboard leds when qemu tells it to. However, I couldn't reproduce this when I tried again :-/
* fix 2 X11 related leaksChristophe Fergeau2011-08-151-0/+1
|
* x11: don't return freed memory from get_clipboardChristophe Fergeau2011-07-181-2/+6
| | | | | | | | | | | | There is a double free in client/x11/platform.cpp. In get_selection(), in the exit: case with ret_val == -1 and data != NULL, *data_ret (which is returned to the caller) has already been assigned "data", so it will be pointing to freed memory when "data" is XFree'd'. Then in handle_selection_notify, get_selection_free is called on this pointer, which causes a double free. When the length of the read data = 0, set the returned value to NULL, this way subsequent free attempts will be a noop. Fixes RH bug #710461
* client: match delete[] with new[]Christophe Fergeau2011-07-181-1/+1
| | | | | vinfo in x11/platform.cpp is allocated using new[] so it needs to be freed with delete[]
* s/USE_OGL/USE_OPENGLChristophe Fergeau2011-05-031-12/+12
| | | | This is more explicit about what it does, and not much longer
* add #include <config.h> to all source filesChristophe Fergeau2011-05-031-0/+3
| | | | | | | | When using config.h, it must be the very first include in all source files since it contains #define that may change the compilation process (eg libc structure layout changes when it's used to enable large file support on 32 bit x86 archs). This commit adds it at the beginning of all .c and .cpp files
* spicec-x11: Work around a bug in xselHans de Goede2011-03-231-1/+3
| | | | | | | | | | | | | | | | | | | | Although ICCCM 2.2. Responsibilities of the Selection Owner: http://tronche.com/gui/x/icccm/sec-2.html#s-2.2 Clearly states (about selection notify events): The owner should set the specified selection, target, time, and property arguments to the values received in the SelectionRequest event. xsel sets the selection notify event target member to the incr atom when it is going to send the clipboard data incremental, rather then setting it to the UTF8_STRING atom (which was the target of the SelectionRequest). Work around this (esp as it is likely other programs may get this wrong too) and accept the incr atom as a valid target in a selection notify event. This fixes Alon's test with running: python -c "print list(range(1000))" | xsel -i -b on the client.
* spicec-x11: Don't crash on apps sending bad atoms as TARGETSHans de Goede2011-03-231-12/+16
| | | | | | | | | Some apps (bad xsel, bad!) send invalid Atoms in their TARGETS property, causing spicec to exit because of an XError. This patch makes spicec survive this scenario. For more info on the xsel bug, see: https://bugzilla.redhat.com/show_bug.cgi?id=690214
* x11: Use _exit rather then exit on X errors (rhbz#680763)Hans de Goede2011-03-011-2/+2
| | | | | | | This avoids us trying to restore the original resolution when we're fullscreen and an X error happens. As restoring fullscreen is a bad idea then as this involves making more X calls, which can get us stuck (in side an XLockDisplay call for example).
* client/server: warning fixes (gcc 4.6.0)Alon Levy2011-01-251-2/+5
| | | | | gcc 4.6.0 added "[-Werror=unused-but-set-variable]", this and the next few fixes tend to that. Mostly harmless.
* spicec-x11: Fix unhandled exception: no window proc crash (rhbz#655836)Hans de Goede2010-11-231-1/+9
| | | | | | | | | | | | | When XIM + ibus is in use XIM creates an invisible window for its own purposes, we sometimes get a _GTK_LOAD_ICONTHEMES ClientMessage event on this window. Since this window was not explicitly created by spicec, it does not have a Window Context (with the event handling function for the window in question) set. This would cause spicec to throw an unhandled exception and exit. This patch replaces the exception throwing with silently ignoring ClientMessage events on Windows without a Context and logging a warning for other event types.
* spicec-x11: Listen for selection owner window destroy / close events tooHans de Goede2010-10-281-3/+15
| | | | | These rarely happen as most apps have the decency to do a SetSelectionOwner None before exiting. But some do not, so listen for these too.
* spicec-x11: Add missing XLockDisplay around XRRSet* callsHans de Goede2010-10-181-0/+10
| | | | | | XRRSet* calls wait for a XReply, so add a missing XLockDisplay, this fixes a hang (due to a race so not always) when switching between windowed and fullscreen mode.
* spicec-x11: add support for image copy and pasteHans de Goede2010-10-151-56/+70
|
* spicec-x11: Put locks around xlib calls which wait for a replyHans de Goede2010-10-111-21/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since libX11-1.3.4 the multi-threading handling code of libX11 has been changed, see: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=933aee1d5c53b0cc7d608011a29188b594c8d70b This causes several issues. One of them is the display inside the client not getting updated when there are no XEvents being generated, this is caused by the following part of the referenced commit message: Caveats: - If one thread is waiting for events and another thread tries to read a reply, both will hang until an event arrives. Previously, if this happened it might work sometimes, but otherwise would trigger either an assertion failure or a permanent hang. We were depending on the otherwise behavior and apparently were lucky. This can be seen by starting F14 in runlevel 3 and then doing startx and not touching the mouse / keyb afterwards. Once you move the mouse (generate an event you see the UI contents being updated but not before. Another thing both I and Alon (iirc) have seen are hangs where 2 threads are stuck in XSync waiting for a reply simultaneously. This might be related to libxcb version, according to the libX11 commit a libxcb newer then 1.6 was needed, and my system had 1.5 at the time I saw this after updating to libxcb 1.7 I can no longer reproduce. This patch tackles both problems (and is needed for the 1st one indepently of the 2nd one possibly being fixed) by adding XLockDisplay calls around all libX11 calls which wait for a reply or an event.
* spicec-x11: Drop annoying useless warningHans de Goede2010-10-061-1/+0
| | | | | | Every time an events comes past where the Window is None (which happens about once every 5 minutes or so), this annoying "invalid window" message gets printed. Remove it!
* spicec-x11: Remove a race window in selection ownership release codeHans de Goede2010-10-061-0/+8
| | | | | | | | | | | Well almost remove it, it was possible that another x11 app would acquire selection ownership, and we would receive a release message from the agent before having processed the xselection ownership change event. Then we would set the selection owner to none, overriding the new owner. As the comment in the patch indicates there still is a minute window left where something similar can happen after this patch. Nothing we can do about that (I blame the libX11 selection API).
* spicec: Move setting of clipboard_owner to guest to platform codeHans de Goede2010-10-061-2/+8
| | | | | | | | | | | | | | Atleast under x11 there is a race condition when setting the clipboard owner to guest from the RedClient code rather then doing it in Platform. After the XSetSelectionOwner() in Platform::on_clipboard_grab(), which runs from the main message loop thread, the x11 event thread can receive a SelectionRequest event from another x11 app, before the RedClient code has set the clipboard owner, which will trigger the owner != guest check in the SelectionRequest event handling code. By moving the setting of the owner in to Platform::on_clipboard_grab() it gets protected by the clipboard lock, which closes this tiny race.
* spicec-x11: make get_clipboard_type handle the None AtomHans de Goede2010-10-041-0/+3
|
* spicec-x11: protect against recursive incr propertiesHans de Goede2010-10-041-0/+4
|
* spicec-x11: If the clipboard was large return the memory to the systemHans de Goede2010-10-041-1/+8
|
* spicec-x11: use malloc / free / realloc for clipboard dataHans de Goede2010-10-041-19/+7
| | | | | | As we need a realloc function it is better to use malloc / free / realloc then to diy, esp. as realloc can grow the buffer without needing a memcpy.
* spicec-x11: Use a queue for XSelectionRequest eventsHans de Goede2010-10-041-59/+119
| | | | | | | | | | | XSelectionRequest events must be answered in the order they were received. But for TARGETS request we can answer directly, where as other requests need to go through the agent. This causes us to handle things out of order, and this can cause us to have more then one requets outstanding with the agent, which is also not what we want. So this patch introduces a queue for XSelectionRequest events, causing us to handle them 1 at a time and always in order.
* spicec-x11: handle multiple types per grabHans de Goede2010-10-041-55/+99
| | | | | And also handle many x11 targets (ie utf8 variants) to a single agent type mapping.
* spicec-x11: Add XFlush calls were neededHans de Goede2010-10-041-0/+10
| | | | | | | | Since we do not always "pump" libX11's event loop by calling XPending (we only call XPending when there is data to read from the display fd), we must always explictly flush any outstanding requests. This patch adds a whole bunch of missing XFlush calls.
* spicec-x11: Force processing of ownerchange event when releasing the cbHans de Goede2010-10-041-0/+13
| | | | | | | | | | | | Make sure we process the XFixesSetSelectionOwnerNotify event caused by us setting the clipboard owner to none, directly after setting the owner to none. Otherwise we may end up changing the clipboard owner to none, after it has already been re-owned because the XFixesSetSelectionOwnerNotify event to owner none is event is still pending when we set the new owner, and then changes the owner back to none once processed messing up our clipboard ownership state tracking. I saw this happening when doing copy twice in succession inside the guest.
* spicec-x11: Request targets from new clipboard ownerHans de Goede2010-10-041-123/+240
| | | | | | | | | | | | | | | Request targets from new clipboard owner, rather then assuming UTF-8 (not entirely complete yet, the last pieces will be in another patch). Atleast as important this code unifies the selection getting code for incr and non incr getting of selection data so that it can be used for both getting regular selection data and for getting targets selection data. This also fixes a big bug in the (I believe untested sofar) incr support code which was interpreting the contents of PropertyNotify events as XSelectionEvents rather then as XpropertyEvents which are completely differen structs!
* spicec-x11: remove clipboard_changer hackHans de Goede2010-10-031-19/+21
| | | | | | | Instead of keeping a flag, we can and should simply check wether the new owner reported in the event it us or not. Also check for the new owner being none and send a clipboard_release when that is the case (through set_clipboard_owner(owner_none)).
* Keep track of clipboard ownershipHans de Goede2010-10-021-0/+13
| | | | | | | | | | | | | Given that all clipboard handling is async, it is possible to for example receive a request for clipboard data from the agent while the client no longer owns the clipboard (ie a VD_AGENT_CLIPBOARD_RELEASE message is in transit to the agent). Thus it is necessary to keep track of our notion of clipboard ownership and check received clipboard messages (both from other apps on the client machine and from the agent) to see if they match our notion and if not drop, or in case were a counter message is expected nack the clipboard message.
* Rename platform clipboard handling functionsHans de Goede2010-10-021-4/+4
| | | | | | | | | | Rename the 4 platform clipboard functions which get called upon receival of an agent clipboard message to on_clipboard_* The old set_clipboard_* names were confusing as they suggest being a class property setter (like set_event_listener) rather then event handler, and set_clipboard_owner was causing a name conflict with the next patch in this series.
* Change VD_AGENT_CLIPBOARD_GRAB to an array of typesHans de Goede2010-10-011-5/+7
| | | | | | | A clipboard owner can indicate that it can supply the data the clipboard owns in multiple formats, so make the data passed with a VD_AGENT_CLIPBOARD_GRAB message an array of types rather then a single type.
* Call intern_atoms() earlierHans de Goede2010-10-011-2/+2
| | | | | We call XFixesSelectSelectionInput with the clipboard_atom, so we musr initialize the atoms before calling XFixesSelectSelectionInput.
* Set clipboard_event before calling send_selection_notifyHans de Goede2010-10-011-1/+1
| | | | | send_selection_notify used the clipboard_event, so set it before calling send_selection_notify.
* wrap XGetAtomNameHans de Goede2010-10-011-1/+9
| | | | | XGetAtomName() throws X11 errors when called on a None atom, so wrap it catching the None case.
generated by cgit (git 2.34.1) at 2024-05-26 01:38:10 +0000