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
19 matches
Mail list logo
