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

[Peter Åstrand]

Hi again!


>>> 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".

I see. VirtualBox is indeed a tricky application.


> 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.

It should work automatically as long as these keys are recognized by the 
client OS, at least with "normal" Linux applications. ThinLinc will 
automatically allocate keycode/keysym pairs in the remote session for 
unknown symbols.


> 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.

Actually, it's all about the client. So if you have problems with sound in 
4.X clients, you can try 3.X clients instead.

Starting with today, old clients are now available for download, see 
http://www.cendio.com/downloads/clients/ .



>> 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?

It's not possible to just replace the "pulseaudio" binary in the client. 
Other things such as the command line arguments have also changed. So you 
need to use a 3.X TL client instead.


Regards, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://cendio.com
Teknikringen 8		http://twitter.com/ThinLinc
583 30 Linköping	http://facebook.com/ThinLinc
Phone: +46-13-214600	http://plus.google.com/112509906846170010689