On Fri, 17 Jan 2014 14:03:10 -0500,
Brian Hinz wrote:
>
> Confirmed that these applications no longer run on TigerVNC/EL6 when the
> server is started with -depth 8
>
But -depth 8 gives you PseudoColor, and I think always has. So it
sounds like the opposite, that your applications need DirectCo
On Fri, 17 Jan 2014 09:11:29 -0800,
Alan Coopersmith wrote:
>
> I think that's more a factor of using a video card driver that doesn't
> simulate PsuedoColor visuals on modern 32-bit graphics cards - I don't
> think we've removed PseudoColor support in Xorg completely, just not
> done much with i
On 1/17/14 11:11 AM, Alan Coopersmith wrote:
> I think that's more a factor of using a video card driver that doesn't
> simulate PsuedoColor visuals on modern 32-bit graphics cards - I don't
> think we've removed PseudoColor support in Xorg completely, just not
> done much with it in years.
Yeah,
On Fri, Jan 17, 2014 at 10:18 AM, Pierre Ossman wrote:
> On Fri, 17 Jan 2014 08:12:58 -0500,
> Brian Hinz wrote:
>
> >
> > I'm not sure when that happened, we just moved to EL6 and I'm not aware
> of
> > anything breaking.
> >
>
> I had a look at one of ours and EL6 does not have a single PseudoC
On 01/17/14 07:18 AM, Pierre Ossman wrote:
> On Fri, 17 Jan 2014 08:12:58 -0500,
> Brian Hinz wrote:
>
>>
>> I'm not sure when that happened, we just moved to EL6 and I'm not aware of
>> anything breaking.
>>
>
> I had a look at one of ours and EL6 does not have a single PseudoColor
> visual on it.
On Fri, 17 Jan 2014 08:12:58 -0500,
Brian Hinz wrote:
>
> I'm not sure when that happened, we just moved to EL6 and I'm not aware of
> anything breaking.
>
I had a look at one of ours and EL6 does not have a single PseudoColor
visual on it. I also could only find 24-bit and 32-bit visuals.
>
On Fri, Jan 17, 2014 at 7:40 AM, Pierre Ossman wrote:
> On Fri, 17 Jan 2014 07:25:32 -0500,
> Brian Hinz wrote:
>
> >
> > I know of at least one major commercial EDA application which requires
> that
> > the server support 8-bit PseudoColor visuals, and a small subset of my
> > users are on a WAN
On Fri, 17 Jan 2014 07:25:32 -0500,
Brian Hinz wrote:
>
> I know of at least one major commercial EDA application which requires that
> the server support 8-bit PseudoColor visuals, and a small subset of my
> users are on a WAN and run Xvnc in 8bpp palette mode specifically for this
> application
On Fri, 17 Jan 2014 06:09:05 -0600,
DRC wrote:
> On 1/17/14 5:17 AM, Pierre Ossman wrote:
> > As far as the code is concerned, both. The protocol still mandates
> > support, hence the simple colour cube to support such clients (of
> > which I expect few).
>
> Let me rephrase. Currently, when doe
On Fri, Jan 17, 2014 at 7:09 AM, DRC wrote:
> On 1/17/14 5:17 AM, Pierre Ossman wrote:
> > As far as the code is concerned, both. The protocol still mandates
> > support, hence the simple colour cube to support such clients (of
> > which I expect few).
>
> Let me rephrase. Currently, when does th
On 1/17/14 5:17 AM, Pierre Ossman wrote:
> As far as the code is concerned, both. The protocol still mandates
> support, hence the simple colour cube to support such clients (of
> which I expect few).
Let me rephrase. Currently, when does that aspect of the protocol get
invoked? My understandin
On Fri, 17 Jan 2014 04:52:28 -0600,
DRC wrote:
>
> Are you referring to colormap support at the RFB level or the X server
> level or both?
>
As far as the code is concerned, both. The protocol still mandates
support, hence the simple colour cube to support such clients (of
which I expect few).
On 1/17/14 4:18 AM, Pierre Ossman wrote:
> Another FYI. As part of the cleanup, I am seriously considering
> removing colour map (i.e. palette) support. Reasons for doing so:
>
> - It's a lot of added complexity for something that is rarely, if at
> all, used today.
>
> - Our current viewer
Another FYI. As part of the cleanup, I am seriously considering
removing colour map (i.e. palette) support. Reasons for doing so:
- It's a lot of added complexity for something that is rarely, if at
all, used today.
- Our current viewer doesn't need it, and remote servers are required
to
On 12/19/13 5:10 AM, Pierre Ossman wrote:
> It is probably also interesting to see what limitations hardware
> decoders put on things. A mobile client with constrained CPU/power
> might benefit from H.264 simply because of the offloading.
Doubtful. If the performance is bandwidth-limited, then th
On Thu, 19 Dec 2013 04:33:23 -0600,
DRC wrote:
> Our interest at the moment is not in providing an automated way of
> switching between multiple encodings but rather to see if H.264 could
> provide generally a better overall solution for low-speed networks. I
> suspect that, for some applicati
On 12/19/13 2:38 AM, Pierre Ossman wrote:
>> Regarding H.264, I have some interest in that as well, but I wasn't able to
>> find a full specification for an H.264 RFB encoding, even though the
>> encoding number is allocated.
>>
>
> I even think there were two of them. I sent out some emails to t
On Wed, 18 Dec 2013 14:48:02 -0600,
DRC wrote:
> Regarding H.264, I have some interest in that as well, but I wasn't able to
> find a full specification for an H.264 RFB encoding, even though the encoding
> number is allocated.
>
I even think there were two of them. I sent out some emails to
Regarding H.264, I have some interest in that as well, but I wasn't able to
find a full specification for an H.264 RFB encoding, even though the encoding
number is allocated.
> On Dec 18, 2013, at 3:27 AM, Pierre Ossman wrote:
>
> Just wanted to give everyone a heads up on what I'm planning f
Just wanted to give everyone a heads up on what I'm planning for the
next few months.
One area we here at Cendio would like to focus on is bandwidth usage
and related user experience (latency, image quality, frame rate, etc.).
In order to tackle this efficiently we believe we need a more flexible
20 matches
Mail list logo
