Actually remove the WId member from the abtract framebuffer class and use the member in xcbframebuffer
qtframebuffer also uses the WId so add a member there
The screen geometry is reported in device independent pixels, so it has
to be multiplied by the devicePixelRatio to get the size of the underlying
framebuffer. Otherwise, only the top left of the screen will be captured.
This matches the behavior of QScreen::grabWindow(...), which also
returns a QPixmap of the given size scaled by devicePixelRatio.
BUG: 419814
The screen geometry is reported in device independent pixels, so it has
to be multiplied by the devicePixelRatio to get the size of the underlying
framebuffer. Otherwise, only the top left of the screen will be captured.
This matches the behavior of QScreen::grabWindow(...), which also
returns a QPixmap of the given size scaled by devicePixelRatio.
BUG: 419814
Summary:
Compute max color values from color masks, instead of relying on unreliable `bits_per_rgb_value` provided by `xcb_visualtype_t`.
In some cases (e.g. nvidia?) `bits_per_rgb_value` contains wrong value. This results in wrong max color values, and causes weird color translation inside libvncserver. Clients will see a screen which is sorta recognizable but in a complete off-color, making krfb unusable.
This is probably a bug in drivers, but x11vnc does not use this value[1], so I guess it's fair to ignore it in krfb too.
[1]: https://github.com/LibVNC/x11vnc/blob/master/src/screen.c#L3442
Reviewers: alexeymin, aacid, #kde_applications
Differential Revision: https://phabricator.kde.org/D25876
Previously used x11 plugin does not compile with Qt5, because Qt5 does
not use Xlib, it uses xcb. Rewrite screen capture plugin from Xlib to
xcb.
I made xcb libs compile required dependency, but availability of X
shared memory extension is checked at runtime. It is used to effectively
get image pixels data, instead of transfering 8Mb over the wire. Xdamage
is used to limit image getting operations only within actually changed
rectangles of screen.
BUG: 377998
Tested on single-monitor system and dual-monitor, where primary monitor
does not start at (0,0) coordinate. Image transfer works fine.
Dual-monitor only has problems with receiving mouse cursor position and
clicks, but this should be fixed outside of framebuffer plugin.
Differential Revision: https://phabricator.kde.org/D5211
