similar to: X11(colortype="true") does not give a truecolor visual (PR#1388)

ripley@stats.ox.ac.uk wrote: > > On Sat, 16 Mar 2002 Edwin@balpol.tudelft.nl wrote: > > > Full_Name: Edwin > > Version: 1.4.1 > > OS: SunOS/Solaris > > Submission from: (NULL) (130.161.1.115) > > > > > > When selecting an X11 visual on Solaris 2.7 with > > > > X11(colortype="true") > > > > a PseudoColor visual

On Sat, 16 Mar 2002 ripley@stats.ox.ac.uk wrote: > On Sat, 16 Mar 2002 Edwin@balpol.tudelft.nl wrote: > > > > The system in question (like many UNIX workstations) has both Pseudo and > > truecolor visual types available, however the default type points to an 8 plane > > PseudoColor visual. > > I believe that is unusual. Sun Xservers allow you to set the default

I have made some modifications to the X11 graphics driver so that it is more flexible about its use of colors. I have added a new parameter to the X11/x11 function which controls this. The parameter is currently called "colormodel" and works as follows: colormodel = 0 Monochrome graphics colormodel = 1 Grayscale (256 shades) colormodel = 2 Pseudocolor1 colormodel = 3

for some reason the following message seems not to have reached the list in the first try, at least I can't find it. my apologies if this is my fault: we are running R under Solaris with SunRay Terminals, which are set to 8 bit color to comply with some other software. In this configuration, X11() opens with colortype=true, i.e., it is not recognized that actually the display is only 8

I've fixed the original report and Tom's first. Someone had incorrrectly arranged for most of the initialization to be done only once per session. I did ask before 1.3.0 what the intention was .... For pseudocolor devices at least this was biting since the palette was not re-initialized. I don't see point two on my system, and Martin's point about interruption was first shown

Hi, I occasionally run out of color in my X11 terminal. At this point, R will issue this error message: Error: X11 cannot allocate additional graphics colors. Consider using colortype="pseudo.cube" or "gray". An immediate x11(colortype="pseudo.cube") doesn't work as the colortype seems to be shared among the different x11 plotting windows. So I have

I'm trying to run an old (~1995) Windows game under Wine, but it requires 256 colours and won't work any higher. I've checked out the 256 colour hacks page and the X methods don't work, because I use the FGLRX drivers and they don't support 8bpp, so I'm trying VNC. I've installed vnc-server and vnc so I can play it through a 256 colour VNC connection, but so far I can

On 21/06/17 04:38 PM, Daniel Vetter wrote: > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote: >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get >> totally obsolete. >> >> I think the gamma_store can end up invalid on error. But the way I read >> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should >>

Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- man/nouveau.man | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/man/nouveau.man b/man/nouveau.man index 87f645a..5c4e4ae 100644 --- a/man/nouveau.man +++ b/man/nouveau.man @@ -13,9 +13,10 @@ nouveau \- NVIDIA video driver .fi .SH DESCRIPTION .B nouveau -is an __xservername__ driver for NVIDIA

Hi, I use R in remote access on a Debian server. I need X11() to create graphical things so I use xvfb-run (Virtual X server environnement) R to allowing X11() capabilities to R. An other technique is to connect in shh -X to execute my R script. With the connection ssh -X, my R script is well executed. BUT when I use Xvfb, some graphics are created but an error occured and stop the script.

I've writen this function (imagenrgb) to display a (m,n,3) array as a RGB image with ngris^3 colors and,optionally, stretching. If option ver=F, it does not display but saves a pseudocolor version of the image as a list (so that subsequent displays are faster). I'd appreciate feedback and improvements and hope that it's useful for others. Example of use: > dim(imatest) [1] 100

There is a bug which I am seeing and a few people are reporting on the forum. The problem is a hidden window which is always rendered on top. It is always short and wide and appears near the bottom-center of the screen. Here is the output from xwininfo on that window, xprop produces nothing. xwininfo: Window id: 0x3400787 (has no name) Absolute upper-left X: 294 Absolute upper-left Y:

Hi, I'm having problems with windows which open off-screen and are thus inaccessible. Until recently, I ran my laptop with an external monitor in a dual-screen configuration. Now, I'm back to a single screen, but some wine apps appear to be trying to start up elsewhere. So, I can verify that the program is running using ps and xwininfo: wtipton 6652 26.5 2.3 2662984 36500 ?

I've put up R-0.64.0.tgz up for FTP from Auckland a little while ago. As usual, don't get it from there unless you are desperate, but wait for it to be mirrored at a CRAN site near you within a day or two. For those who *are* desperate, I've left a copy in ftp://blueberry.kubism.ku.dk/pub/R-devel/R-0.64.0.tgz (Be gentle, that's my desktop PC!) There's also a version split

I've put up R-0.64.0.tgz up for FTP from Auckland a little while ago. As usual, don't get it from there unless you are desperate, but wait for it to be mirrored at a CRAN site near you within a day or two. For those who *are* desperate, I've left a copy in ftp://blueberry.kubism.ku.dk/pub/R-devel/R-0.64.0.tgz (Be gentle, that's my desktop PC!) There's also a version split

Need some pointers here. I've got CentOS 4.4, and I want to control my OSX 10.4.9 box via VNC. It connects, and I get a little dot for the mouse cursor, but just a black screen. I can see the mouse controlling the OSX desktop... Here's the output when I start in a terminal: [d at f ~]$ vncviewer VNC server supports protocol version 3.889 (viewer 3.3) VNC authentication succeeded

Not clear what the depth % 8 was trying to protect against, but it was breaking 30bpp visuals with DRI3. Add it in to ensure that bitsPerPixel % 8 is 0, since there is plenty of bpp/8 math in the driver. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nouveau_dri2.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c

Hi all, these are the remaining unapplied patches of the ARM HDLCD patch series. Changes in v7: - rebased on b61ed421d2c85b5b106c63f2c14f8aa162b282f0; - turn more printk and panic into early_printk and early_panic. Changes in v6: - rebased on 77d3a1db3196b1b5864469f8d3f41d496800c795; - remove useless initializations to NULL in lfb_init; - more compact checks in lfb_init. Changes in v5: - move

Anyone know how can I fix Half-Life problem? : "Half Life need at least a 16bit color depth to run, usually this is "32768" or "65535" colors" I tried many settings in config, and it doesn't work. I have Wine 20010809 from Debian binaries ( other versions don't work too ) and X 4.1.0 with TrueColor (24bpp) color depth on Nvidia card. -- Pozdrawiam Jakub

As part of preparation for a ``visualization'' course I am supposed to teach I had a brief play with using the Gimp to capture an on-screen R plot and then massaging it into something more suitable for magazine publication :-). You can see the result at ftp://stat.auckland.ac.nz/pub/ihaka/plot.jpg It looks best in truecolor. Ross