Skip to main content

启用compiz和fglrx时的vnc问题 | Problem of vnc server with compiz and fglrx enabled

困扰了我近两年的问题。

远程连vnc回我的电脑,第一个画面能看到,鼠标也可以动,但是键盘按没反应,画面也不会再动。
一开始以为是网络问题,或者是设置了view only,但是本机上看,鼠标和键盘都得到了响应,所以只是屏幕刷新的问题。

这个问题我一直不知道原因。 但是最近新装的ubuntu,一开始是可以连得,没有问题,我还以为是更新了解决了这个问题。但是最近又不行了,我才开始想最近改了什么设置。 最后发现原来是启动了fglrx,关了radeon。 改回radeon后vnc又复活了。

于是查了一下, 果然是个bug,见https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/353126, 而且nvidia的闭源驱动也有这个问题,我以前是用的nvidia的卡,只是一直用它的驱动,所以没有发现这个问题。



A problem that has been bothering me for nearly two years.

So the problem is, when trying to remotely connect to the vnc server enabled on my computer, I can see only the first screenshot, without further update, the mouse pointer is moving, but keyboard events are not responded.
I thought at first this must be something wrong with the network, or maybe "view only" is set on the server, however on my computer I see that mouse and keyboard are working properly, so it's only the problem of screen updating.

I didn't know the reason all the time until now. Recently I have a new Ubuntu installed on my computer, in the first few days vnc server was working well, and I had thought that this problem had been solved in this new version of Ubuntu. However vnc failes again these days, and I begin trying to remember what I have changed in the system. In the end I found that I've enabled fglrx and disabled radeon. And vnc come back to alive after switching back to radeon.

Later I found that it's indeed a bug, see https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/353126, which also affects the nvidia proprietary driver. I was using nvidia cards before, but I had always been using its proprietary driver, and that's why I didn't find the cause before.

Comments

Popular posts from this blog

A Rocky Migration: Moving from docker-compose to Podman and gVisor

I've been running a few containers for several years. They were all running under rootless Docker with a single user. Initially, I planned to  migrate the containers to VMs , but I couldn't get a stable workflow after about two months of effort. Later,  gVisor caught my attention , and I decided to migrate to Podman with gVisor instead. The new plan is to run each container with  --userns=auto  and use Quadlet for systemd integration. This approach provides better isolation and makes writing firewall rules easier. I'm now close to migrating all my containers. Here are a couple of rough edges I'd like to share. Network Layout I compared  various networking options  and spent a few hours trying the one-interface-per-group approach before giving up. I settled on a single macvlan network and decided to use static IP addresses for my containers. To prevent a randomly assigned IP address from conflicting with a predefined one, I allocated a large IP range for my ...

Exploring Immutable Distros and Declarative Management

My current server setup, based on Debian Stable and Docker, has served me reliably for years. It's stable, familiar, and gets the job done. However, an intriguing article I revisited recently about Fedora CoreOS, rpm-ostree, and OSTree native containers sparked my curiosity and sent me down a rabbit hole exploring alternative approaches to system management. Could there be a better way? Core Goals & Requirements Before diving into new technologies, I wanted to define what "better" means for my use case: The base operating system must update automatically and reliably. Hosted services (applications) should be updatable either automatically or manually, depending on the service. Configuration and data files need to be easy to modify, and crucially, automatically tracked and backed up. Current Setup: Debian Stable + Docker My current infrastructure consists of several servers, all running Debian Stable. System Updates are andled automatically via unattended-upgrades. Se...

mkosi: First Impressions

I stumbled upon the Gentoo wiki page for systemd-nspawn , which in turn led me to nspawn.org , mkosi , and later systemd-sysupdate . mkosi quickly caught my eye because it's almost exactly what I wanted to build myself, as mentioned in a previous post . So, I decided to spend my "sysadmin fun quota" on it. Overview mkosi is similar to docker build or podman build , but it's designed for creating full OS images. It focuses on development and testing. For example, much like nix-shell , mkosi can quickly launch a sandboxed shell with a specific distribution and selected packages installed. The systemd project itself uses mkosi for testing across different distros. The re-introduction article  is a great read. Speed Note that this is by no means a rigid benchmark. My setup is an SSD with LUKS and an ext4 filesystem (without reflink support). Building Container Images mkosi is pretty fast. A simple mkosi command creates a fresh Debian image. I used the --incrementa...