#StackBounty: #x11 #xorg #firefox Block Screen Sharing

Bounty: 50

Is there any part of my system that I can block access to from the firefox process on a Linux system that will break screen sharing?

I noticed during a video call that Firefox has the ability to do screen sharing, which means the process can read the contents displayed on my screen.

I don’t like the idea of everything on my screen being available to my browser, whats the mechanism behind this?


Get this bounty!!!

#StackBounty: #xorg #20.10 #synergy Possible with x2x to have cut/paste work between Ubuntu PCs?

Bounty: 50

My question is: has anyone successfully got cut/paste working over x2x between two Ubuntu PCs? Is it possible? As I can’t find any documentation/examples only a few references in articles saying it should/could/might work.

If it’s not possible I would like to know if it’s actually possible by other means (Barrier? Synergy?).

I already use x2x to control a Ubuntu 20.10 PC with my main PC’s keyboard mouse (also Ubuntu 20.10) and it works great, but no cut/paste.

I read a few articles which say that if you start x2x using an alternative method (this needs some tweaks like xhost and other config to have tcp port 6000 listening) then cut/paste should work but although I can get x2x working with either method I have had no luck getting any sort of cut/paste working.

e.g. forwarding method:

ssh -X remote_machinename_or_ip_address x2x -direction_of_the_remote_display -to :0

and second alternative method:

x2x -to IP_or_hostname:0.0 -direction_of_the_remote_display


Get this bounty!!!

#StackBounty: #fonts #xorg #dpi #x-windows #high-dpi X Logical Font Description and HiDPI

Bounty: 50

The problem: X-server serves fonts at a fixed resolution of 100dpi, rather than the current window system resolution (xdpyinfo | grep -F resolution).

A bit of theory. There are legacy server-side fonts which are sent to X clients over the network (via TCP or UNIX socket) either by the X server itself, or by a separate X Font Server (single or multiple). Unlike the usual client-side fonts (Xft, GTK 2+, Qt 2+), the "server" backend (also called the core X font backend) does not support anti-aliasing, but supports network transparency (that is, bitmaps, without any alpha channel, are sent over the network). At the application level, server-side fonts are specified not as an XftFontStruct (which most often translates into the familiar DejaVu Sans Mono:size=12:antialias=true), but as an XLFD. If we are talking about a local machine, then the same font file can be registered in both font backends at once and be available to both modern GTK and Qt-based applications, and legacy ones (Xt, Athena, Motif, GTK 1.2, Qt 1.x).

Historically, there were raster server-side fonts (*.pcf), and a raster has a resolution of its own (not necessarily the same as the window system resolution). Therefore, XLFD has fields such as RESOLUTION_X and RESOLUTION_Y. For a raster font not to look ugly when rendered onto the screen and still have the requested rasterized glyph size (PIXEL_SIZE), the raster resolution must be close to the screen resolution, therefore raster fonts were usually shipped with native resolutions of 75dpi and 100dpi (that’s why we still have directories such as /usr/share/fonts/X11/75dpi and /usr/share/fonts/X11/100dpi). So, the below lines represent the same 12 pt font

-bitstream-charter-bold-r-normal--12-120-75-75-p-75-iso8859-1
-bitstream-charter-bold-r-normal--17-120-100-100-p-107-iso8859-1

with a rasterized glyph size of

  • 12px at 75dpi, and
  • 17px at 100dpi, respectively.

But, in addition to raster fonts, there are vector, or outline fonts (TrueType, OpenType, Adobe Type 1), which can be scaled by any factor and still look good when rendered onto the screen. Some X-server implementations (notably, XSun) also supported the Adobe Type 3 format, where glyphs were described using the Turing-complete PostScript language.

Of course, the concept of raster resolution does not apply to vector fonts, so I can request zeroes (0) or even asterisks (*) in the RESOLUTION_X and RESOLUTION_Y fields, and, in theory, my X server should give me exactly the font requested. This is directly stated in the Arch Linux Wiki article at the link above:

Scalable fonts were designed to be resized. A scalable font name, as shown in the example below, has zeroes in the pixel and point size fields, the two resolution fields, and the average width field.

To specify a scalable font at a particular size you only need to provide a value for the POINT_SIZE field, the other size related values ​​can remain at zero. The POINT_SIZE value is in tenths of a point, so the entered value must be the desired point size multiplied by ten.

So, either of the following two queries should return a 12pt Courier New font at the window system resolution:


-monotype-courier new-medium-r-normal--*-120-*-*-m-*-iso10646-1
-monotype-courier new-medium-r-normal--0-120-0-0-m-0-iso10646-1

Or so I thought. The thing is, after migration from 96…115dpi monitors to a 162dpi 4k monitor, I noticed that my carefully selected vector fonts suddenly became too small.

And it turned out that unless you explicitly set RESOLUTION_X and RESOLUTION_Y fields to 162 (and no one in his right mind would do so — it would require rewriting dozens of Xresources lines every time one changes his monitor), then X server defaults to rendering the font at 100dpi instead of 162. The difference between 17 and 27 pixels (the factor of 1.62 = 162 / 100) is quite noticeable. Here’s an example for a modern Debian 10 box:

Debian 10, Courier New 12pt at 162dpi

I thought this regression was a consequence of people gradually cutting out obsolete subsystems from X11, but in Debian Woody, released in 2002 and having a 2.2 kernel, I saw exactly the same thing:

Debian 3, Courier New 12pt at 162dpi

The only difference is that Debian Woody renders fonts in a "cleaner" manner, apparently, applying hinting on the server side, before sending bitmaps over the network.

So this is not a regression. The problem has always been there and equally affects all vector font types (TrueType, OpenType, Type 1).

Now, the question. Is there a way, without hard-coding window system resolution into user settings for each individual resource, to get by with less pain than recommended by the author of the Sharing Xresources between systems article?

Is it possible to solve the problem by changing the global configuration of the X server itself or the libraries it relies on (libfreetype, libxfont)?


Get this bounty!!!

#StackBounty: #kernel #keyboard #xorg #xserver #dead-keys Keyboard buffer issue with multi-byte characters (latin, diacritics) / dead k…

Bounty: 50

I write in Spanish and sometimes I use diacritics (ie multi-byte chars) with dead keys, for example "liberación" ("liberation" in Spanish). Usually I don’t have any problem, but when the GUI freeze or for any reason it can’t handle more input, when the text shows up the diacritic char jump to the first position on the/a keyboard buffer, displaying something like "óliberacin", which is very annoying since occur very often while chatting or writing an email (easier to test: aaaááaaa). Maybe a xserver or GNOME Shell or a kernel bug?

I have this problem since more than four years now, with several kernels, Ubuntu versions, hardware and versions of Firfeox and Chorme. I couldn’t find any pattern neither something strange on dmesg/journalctl//var/log files…

Setup: This happened to me since Ubuntu 16.04 LTS fresh install, kernel 4.4.0-62-generic; and even recently with 18.04 and 4.15.0-134-generic, GNOME Shell 3.28.4.

$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=es_AR.UTF-8
[...]
$ im-config -l
ibus xim
$ im-config -m
default
missing
ibus 

ibus
$ env | grep "XMODIFIERS|IM_"
XMODIFIERS=@im=ibus
CLUTTER_IM_MODULE=xim
QT_IM_MODULE=ibus
IM_CONFIG_PHASE=1
QT4_IM_MODULE=xim
GTK_IM_MODULE=ibus

How can I debug to find where the problem might be?

Update 2021-01-23

I didn’t cross with this issue for a while, until today, typing from Desktop to Android (GSconnect→KDE Connect Keyboard).

screenshot


Get this bounty!!!

#StackBounty: #xorg #multiple-monitors #vnc video-dummy – The Fake display with/without monitor connected at the same time

Bounty: 100

I have installed the xserver-xorg-video-dummy-hwe-18.04 to let I use the VNC without needs to connect HDMI cable to my ubuntu machine.

I followed the Topic here, and successfully able to use VNC connect to Ubuntu machine without plugged-in monitor.

However, there are side effect is that, if I connect the HDMI cable to the ubuntu machine, it will display _ (black screen with cursor blinking at the top) and not show lightdm login screen as expected.

If I remove /etc/X11/xorg.conf from directory, reboot, I can now back using the monitor plugged-in.

Question

Are there possible to able to use video-dummy with/without monitor at the same time? may be like secondary mirroring display mode. How to config /etc/X11/xorg.conf properly?

So that I can use the desktop no matter real monitor has connected to HDMI port or not.


Get this bounty!!!

#StackBounty: #drivers #nvidia #graphics #xorg Setting the Coolbits in 20.04 without blowing X

Bounty: 50

I’m trying to set the Coolbits in 20.04 in order to gain manual gpu fan control.

I edited the nvidia the X configuration file 10-nvidia.conf already present in /usr/share/X11:

Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "Coolbits" "28"
    ModulePath "/usr/lib/x86_64-linux-gnu/nvidia/xorg"
EndSection

Note that I just added Option "Coolbits" "28"

This didn’t have any effect whatsoever.

What is the correct way of setting the coolbits in 20.04, given my configuration?


Get this bounty!!!

#StackBounty: #gnome #keyboard #xorg #gdm why am i getting ' event processing lagging behind' msg in Ubuntu 20.10

Bounty: 50

seeing my system logs, they are full of msgs like this:

/usr/libexec/gdm-x-session[2564]: (EE) event4  - SIGMACHIP USB Keyboard: client bug: event processing lagging behind by 25ms, your system is too slow
/usr/libexec/gdm-x-session[2564]: (EE) event4  - SIGMACHIP USB Keyboard: client bug: event processing lagging behind by 17ms, your system is too slow

i have a 12 core system which is essentially idle when i see this. it seems to happen since i upgraded to Ubuntu 20.10.

how can i find the root cause and how to eliminate this issue?

sys info:

model name  : AMD Ryzen 9 3900X 12-Core Processor
/sys/devices/system/cpu/cpufreq/policy10/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand


grep . /sys/devices/system/cpu/cpuidle/*
/sys/devices/system/cpu/cpuidle/available_governors:ladder menu teo 
/sys/devices/system/cpu/cpuidle/current_driver:acpi_idle
/sys/devices/system/cpu/cpuidle/current_governor:menu
/sys/devices/system/cpu/cpuidle/current_governor_ro:menu


Get this bounty!!!

#StackBounty: #gnome #keyboard #xorg #gdm why am i getting ' event processing lagging behind' msg in Ubuntu 20.10

Bounty: 50

seeing my system logs, they are full of msgs like this:

/usr/libexec/gdm-x-session[2564]: (EE) event4  - SIGMACHIP USB Keyboard: client bug: event processing lagging behind by 25ms, your system is too slow
/usr/libexec/gdm-x-session[2564]: (EE) event4  - SIGMACHIP USB Keyboard: client bug: event processing lagging behind by 17ms, your system is too slow

i have a 12 core system which is essentially idle when i see this. it seems to happen since i upgraded to Ubuntu 20.10.

how can i find the root cause and how to eliminate this issue?

sys info:

model name  : AMD Ryzen 9 3900X 12-Core Processor
/sys/devices/system/cpu/cpufreq/policy10/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand


grep . /sys/devices/system/cpu/cpuidle/*
/sys/devices/system/cpu/cpuidle/available_governors:ladder menu teo 
/sys/devices/system/cpu/cpuidle/current_driver:acpi_idle
/sys/devices/system/cpu/cpuidle/current_governor:menu
/sys/devices/system/cpu/cpuidle/current_governor_ro:menu


Get this bounty!!!

#StackBounty: #gnome #keyboard #xorg #gdm why am i getting ' event processing lagging behind' msg in Ubuntu 20.10

Bounty: 50

seeing my system logs, they are full of msgs like this:

/usr/libexec/gdm-x-session[2564]: (EE) event4  - SIGMACHIP USB Keyboard: client bug: event processing lagging behind by 25ms, your system is too slow
/usr/libexec/gdm-x-session[2564]: (EE) event4  - SIGMACHIP USB Keyboard: client bug: event processing lagging behind by 17ms, your system is too slow

i have a 12 core system which is essentially idle when i see this. it seems to happen since i upgraded to Ubuntu 20.10.

how can i find the root cause and how to eliminate this issue?

sys info:

model name  : AMD Ryzen 9 3900X 12-Core Processor
/sys/devices/system/cpu/cpufreq/policy10/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand


grep . /sys/devices/system/cpu/cpuidle/*
/sys/devices/system/cpu/cpuidle/available_governors:ladder menu teo 
/sys/devices/system/cpu/cpuidle/current_driver:acpi_idle
/sys/devices/system/cpu/cpuidle/current_governor:menu
/sys/devices/system/cpu/cpuidle/current_governor_ro:menu


Get this bounty!!!

#StackBounty: #gnome #keyboard #xorg #gdm why am i getting ' event processing lagging behind' msg in Ubuntu 20.10

Bounty: 50

seeing my system logs, they are full of msgs like this:

/usr/libexec/gdm-x-session[2564]: (EE) event4  - SIGMACHIP USB Keyboard: client bug: event processing lagging behind by 25ms, your system is too slow
/usr/libexec/gdm-x-session[2564]: (EE) event4  - SIGMACHIP USB Keyboard: client bug: event processing lagging behind by 17ms, your system is too slow

i have a 12 core system which is essentially idle when i see this. it seems to happen since i upgraded to Ubuntu 20.10.

how can i find the root cause and how to eliminate this issue?

sys info:

model name  : AMD Ryzen 9 3900X 12-Core Processor
/sys/devices/system/cpu/cpufreq/policy10/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand


grep . /sys/devices/system/cpu/cpuidle/*
/sys/devices/system/cpu/cpuidle/available_governors:ladder menu teo 
/sys/devices/system/cpu/cpuidle/current_driver:acpi_idle
/sys/devices/system/cpu/cpuidle/current_governor:menu
/sys/devices/system/cpu/cpuidle/current_governor_ro:menu


Get this bounty!!!