[Thinlinc-technical] ThinLinc 4.1.0 beta now available - some feedback

[Andreas v. Heydwolff]

Hi Peter,

thanks for your reply.

>> I take it from the last xkb related thread on the list it is desired
>> behaviour that currently the KDE settings are not modifying anything and
>> the IGEL keyboard settings are being replicated in the native Linux and
>> VBox Windows environments.
> 
> Yes, more or less. The KDE settings should change the server side
> layout. In most cases, the end result is the same. 

Hm, they don't. I've tried US, TR and GR keyboards but I always get the
IGEL's DE settings, not even garbled stuff that would indicate at least
some change.

However, if you have
> problematic/legacy applications, set the server side layout to the same
> as the client side layout. 

This is the default anyway, DE on Server -> DE on IGEL

> For VirtualBox and other virtual machines,
> you should also set the same layout in the virtual machine.

I have DE on the TL server and IGEL Linux, and DE in VBox Windows

>> There are four glitches I found in VBox Windows machines:
>>
>> The lower case key left of the "1" key (^, ZIRKUMFLEX on German
>> keyboards) produces in a Windows machine Ctl-Alt-ä [auml] instead of
>> ZIRKUMFLEX, and
>>
>> AltGr-4 produces Ctl-Alt-<
>> AltGr-5 produces Ctl-Alt-<
>> AltGr-6 produces Shift-Ctl-Alt-<
> 
> The german circumflex is a "dead" key, and those are always a little bit
> tricky. 

Not necessarily but currently it is and the DE variant "eliminate dead
keys" does not change anything, just as changing the kb language does
not change anything.

Is it correct that these problems occurs despite setting a
> German layout both on the client side, in KDE, and in VirtualBox?

Yes. I do get the degree sign with Shift-^ in Linux and VBox alike, a
dead ^ in Linux but nothing when hitting the ^ key in my VBox Windows
once or twice, and ^ once and then an "a" only yields a genuine "a".

The server was configured to run a trial of SunRay software long ago but
I think I completely undid even in TL 3.0 times the changes that were
necessary for the Sun keyboard and keyboard layouts to work with the SRSS.

A small addendum: As I like the Sun keyboard (and I am sure some others
coming from Sun Ray may still use them too), would it in principle be
possible to get the Sun kbd's F13-F20 keys (and even the sound keys
above the numeric pad) working once the problem with the not working
layouts is solved? They are very useful for me for shortcuts in KDE.

And: The laptop keys (DELL int'l 105 PC with DE layout) worked perfectly
in the current state of affairs when reconnecting to the disconnected
session that used a Sun 5/6 DE layout, at least nominally - perhaps
these were actually the IGEL int'l 105 DE keys, who knows).

About sound:

> Since ThinLinc 4.0.0, we are shipping PulseAudio 2.1. In some cases, it
> works great, but sometimes it does not. 

Hm. Debian Wheezy uses 2.0, and I think before TL 4.0 it worked. I never
found/took the time though to revert to some TL 3.x.x server as you had
suggested in a previous posting.

> We have a bug for this:
> https://www.cendio.com/bugzilla/show_bug.cgi?id=4411

The faulty prebuffering explanation makes perfect sense to me. I sort of
doubt, though, whether an upgrade to 3.0 should be a first step towards
a solution on a stable Debian machine. Checking version numbers I now
even see that Debian testing ("Jessie") still has a version 2.0-6.1
while unstable sports pulseaudio 4.0-3

Makes me want to try an older (pre TL 4.0) pulse implementation. Would
it be a viable testing scenario for you to send me and for me to throw
into the appropriate IGEL custom partition TL 4.1 beta thinlinc dir the
pre TL 4.0 TL pulseaudio binaries and config files (was that pulse 2.0
perhaps, like in current Debian)? Or are the pulse files too closely
dependent on other code that would not match any more?

> This seems to be a generic PulseAudio ("upstream") problem. Hopefully we
> will be able to take a look at this in a near future.

Thank you, and greetings,

Andreas