summaryrefslogtreecommitdiffstats
path: root/client
Commit message (Collapse)AuthorAgeFilesLines
...
* gitignore: add generated_*, vim temps, pycAlon Levy2010-11-081-0/+4
|
* spicec-win: ignore MSVCRT.lib in x86 buildArnon Gilboa2010-11-081-2/+3
| | | | Same as in x64 build, for using the updated wspice-0.6.3
* spicec: Make cegui log to <app_data_dir>/cegui.logHans de Goede2010-11-051-1/+8
| | | | | | This stops the client from dropping CEGUI.log files into the cwd all the time, and stops it from crashing when the cwd is not writable (rhbz#650253).
* 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.
* client: add verbose link error messagesAlon Levy2010-10-251-1/+19
|
* spicec-tests: add controller_test (v2)Arnon Gilboa2010-10-254-0/+424
| | | | use chars for title & menu instead of wchars
* spicec-win: remove redundent strdup & buggy freeArnon Gilboa2010-10-251-5/+4
| | | | | text refered a substr of item_dup and was used after free(item_dup). no need to strdup, we can destroy the resource string.
* controller: Make menu text utf-8Hans de Goede2010-10-252-22/+19
| | | | | | We are making all text send over the controller socket utf-8, rather then having somethings as 8 bit (hostname) and others (title, menu) unicode16, this patch completes this change by converting the menu handling.
* spicec-x11: Do not set _NET_WM_USER_TIME to 0 on startupHans de Goede2010-10-252-5/+7
| | | | Setting _NET_WM_USER_TIME to 0 means we do not want focus, not good.
* spicec-win: add x64 to vcproj & sln (v2)Arnon Gilboa2010-10-252-0/+242
| | | | use CEGUI for x64 as well, no need for the SUPPORT_GUI hack
* spicec-win: map title string from utf8 to utf16Arnon Gilboa2010-10-251-1/+8
| | | | Fix win client broken by the utf8 patch.
* spicec-win: add #ifndef _WIN64 for u/intptr_t typedefsArnon Gilboa2010-10-241-1/+3
|
* spicec-win: Replace Set/GetWindowLong to LongPtr for x64 competabilityArnon Gilboa2010-10-241-5/+5
|
* Remove no longer used wstring_printf functionsHans de Goede2010-10-214-42/+0
|
* client: Interpret the title control message as utf8 instead of unicode16Hans de Goede2010-10-219-23/+19
| | | | | | | The activex browser plugin is sending unicode16 text, where as the xpi one is sending utf8 text. After discussing this on irc we've decided that utf8 is what we want to use. So the client (this patch), and the activex will be changed to expect resp. send utf8 text as the title.
* spicec-x11: Change source of controller socket name, fixing CVE-2010-2792Hans de Goede2010-10-211-4/+8
| | | | | | | | | | | | | | | | | The socket name used to communicate between the xpi browser plugin and the spicec was predictable allowing a non priviliged user on the same system to create the socket before spicec does and thus intercept the messages from the xpi to the client, including login credentials. This security vulnerability has been registred with mitre as CVE-2010-2792: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2792 This patch changes the controller code to instead read the socket name from an environment variable which gets set by the xpi before executing the spicec, making the socketname private between the client and the xpi. Note that this means that the controller will only work with an xpi which has matching changes, the changes are present in the latest version of the xpi as available as update for / with RHEL-5.5 and RHEL-6.0 .
* Make the gui use Application::hide_gui rather then hide_meHans de Goede2010-10-183-5/+3
| | | | | | | | Now that Application::hide_me actually does what the name suggests (hide the entire client, ie all client windows), the gui using it to not show the gui layer leads to the entire client disappearing when one presses close in the GUI or dismisses a GUI dialog. This patch makes the GUI code call hide_gui instead of hide_me, fixing this.
* spicec-x11: Fix window management under KDEHans de Goede2010-10-182-0/+13
| | | | | | | | | | | | | | There were 2 issues with window management under KDE 1) When an app does its own focus management like we do, kwin expects an explicit raise for the app to get to the top, so we did have focus, but would have other windows (partially) covering the client window -> do a raise after setting focus to ourselves 2) When switching from fullscreen <-> window, we unmap and remap our window, then set focus to ourselves. kwin thinks this means we're trying to steal the focus without the user asking for it. This patch makes us set the _NET_WM_USER_TIME property on our window, this helps kwin's focus stealing code to see that we are really not stealing the focus, just responding to a user event.
* client: change monitor mode setting <-> fullscreen window mode setting orderHans de Goede2010-10-181-2/+2
| | | | | | | | | | | 1) Make the order when starting up in fullscreen mode the same as when switching from window -> fullscreen: First set the mode, then make the window fullscreen 2) Change the order when leaving fullscreen mode, first restore the original monitor mode, then make the window non fullscreen. Changing the monitor mode in X11 causes the window manager to re-arrange windows, and if this happens while compiz is busy mapping the window it gets confused and maps the window with a maxmimized size.
* spicec-x11: Change WmSizeHints in fullscreen modeHans de Goede2010-10-182-21/+38
| | | | | | Some window managers will ignore the fullscreen hint, unless WmSizeHints allow them to resize the window so that they can give it the size of the roo-window. This fixes fullscreen mode in compiz.
* 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.
* client: Do not try to send display_config until we've received the agent capsHans de Goede2010-10-181-9/+4
| | | | | | | | | | | Currenty, we check the agent caps in RedClient::handle_agent_connected for VD_AGENT_CAP_DISPLAY_CONFIG and if present send display_config, but at this time we have not received the caps yet, so remove this. Also the send_agent_display_config call in on_agent_announce_capabilities lacks a check for _agent_disp_config_sent, and we send the display config before announcing that we may do so by sending our own caps, which seems inpolite.
* spicec: add controllerArnon Gilboa2010-10-187-31/+700
| | | | | | | | | | | Spice client controller enables external control (e.g., by XPI or ActiveX) of the client functionality. The controller protocol enables setting parameters (host, port, sport, pwd, secure channels, disabled channels, title, menus, hotkeys etc.), connecting the server, showing and hiding the client etc. The controller is based on the cross-platform named pipe.
* spicec: add foreign menuArnon Gilboa2010-10-187-10/+574
| | | | | | | | | Spice foreign menu enables external control of the client menu. The foreignmenu protocol enables an external application to: add a submenu, set its title, clear it, add/modify/remove an item etc. Foreign menu is based on the cross-platform named pipe.
* spicec-win: move named_pipe definesArnon Gilboa2010-10-172-3/+4
|
* spicec-win: fix menu id push to free_sys_menu_idArnon Gilboa2010-10-171-1/+1
|
* spicec: enable multiple CmdLineParser instantiationsArnon Gilboa2010-10-171-0/+5
| | | | | Used by controller. One instance at a time, not thread-safe. Add basename() for win32.
* spicec: name host paramArnon Gilboa2010-10-171-1/+1
|
* spicec: add ProcessLoop::on_start_running()Arnon Gilboa2010-10-172-1/+2
|
* spicec: extract RedScreen::update_menu()Arnon Gilboa2010-10-172-2/+8
|
* spicec: add menu id & find_sub()Arnon Gilboa2010-10-172-2/+21
|
* spicec-x11: add support for image copy and pasteHans de Goede2010-10-151-56/+70
|
* Replace epoll with select in X clientAlexander Larsson2010-10-122-218/+97
| | | | | | | | The use of epoll in the client is totally overkill in terms of scalability, and its a problem for portability. The OSX port converts this to use select, but keeps some of the old complexities in the code. This new patch makes it simpler and look much more like the windows code.
* spicec-x11: Put locks around xlib calls which wait for a replyHans de Goede2010-10-114-44/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* spice-win: handle multiple types on clipboard grab send & receiveArnon Gilboa2010-10-111-19/+36
|
* spice-win: remove clipboard_changer hackArnon Gilboa2010-10-111-9/+2
| | | | Instead of keeping a flag, we simply check wether the new owner is us or not
* spice-win: handle type VD_AGENT_CLIPBOARD_NONE in ↵Arnon Gilboa2010-10-111-1/+10
| | | | Platform::on_clipboard_notify()
* spice-win: remove windows-specific bitmap cut & paste supportArnon Gilboa2010-10-111-17/+0
| | | | will wait until png comes in
* spicec: Do not try to do accounting of pci memoryHans de Goede2010-10-093-40/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch spicec reproducely hangs in GlzDecoderWindow::pre_decode_update_window(). When GlzDecoderWindow::will_overflow() returns true, GlzDecoderWindow::pre_decode_update_window(), waits for a call to GlzDecoderWindow::post_decode() to free up some memory This happens even though there still is pci memory available (otherwise the driver would not have been able to send an image to decode in the first place). The GlzDecoderWindow::post_decode() call never happens as the server is waiting for a reply to the decode of the hanging image, causing the client to hang for ever. This patch fixes this by simply removing the "attempted" pci memory accounting. As there is no need for that, as the driver already must keep track of pci memory usage. I've verified that both the old and new Xorg drivers take care of not overusing the pci memory themselves I would expect the same to be true for the windows driver. Note the calculating of the glz_window_size in red_client.cpp cannot be removed as the calculated value is send as part of the SpiceMsgcDisplayInit on connect.
* spicec: only send display-config if the agent can handle itHans de Goede2010-10-061-2/+3
|
* 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: don't send agent messages directly from ClipboardListener callbacksHans de Goede2010-10-062-6/+59
| | | | | | | | ClipboardListener callbacks can run from another thread then the main channel loop thread, where agent messages are normally dispatched from. So they may not send agent messages directly, instead they should post events to the main channel loop.
* 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-064-3/+17
| | | | | | | | | | | | | | 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.
generated by cgit (git 2.34.1) at 2025-09-27 12:12:50 +0000