if you are curious to see how it's the done, equis' specific code is in
/n/sources/contrib/fgb/root/sys/src/ape/X11/cmd/X/hw/equis
ah, and if you don't want to grab the full source (which is quite big)
you can just fcp the binary /n/sources/contrib/fgb/root/386/bin/equis
you'd also need some fonts in /sys/lib/ape/X11/fonts
enjoy!
Federico G. Benavento
---
/bin/fortune:
Program in place to shed costs
And after that, how do I run? I get some errors and a big X after
X11/equis
you run it just like any other X server, equis -help is a bit verbose
I run it:
% equis -ac
--
Federico G. Benavento
I'd just like to comment... After a loooooong contrib/install, I got
equis running, launched an xterm from my Linux box, and now I'm
running twm and Firefox on the Plan 9 box. Rio is no longer running
on said box. X is pretty fast considering that it's going over the
network... good job Federico! I get asked all the time "Does it have
X?" and while I will still answer "Plan 9 is based on a different
graphics system", I'll now be able to add, "but we have X11 too".
I would post a screenshot but it looks just like any Linux box running
TWM.
John
when I drawterm from a mac to a plan 9 box it works fine.
(once I realized that I can only use a DISPLAY of :0
if localhost is a known system name, which it wasn't on my system)
when I run it in plan 9 in parallels on the mac it looks a bit funny,
but if you learned to read and write slanted letters at school
everything is ok :-)
http://plan9.cs.utwente.nl/equis-parls.png
I have not investigated yet; do you have an idea?
anything I could/should try?
Axel.
I feel stupid - how do I check screen depth?
ehm... I added xdpyinfo output at the end.
anyway, the main issue is not screen depth.
(ok. I see somewhat different colors for the twm bars
between parallels and drawterm, using same twm.
this might be creen depth related)
the main issue could very well be an issue in parallels.
it has something to do, not with when equis is started,
but with when a window is created in rio - whether
parallels is running full screen, or in a big window
(screen-sized) with top-left corner not at top-left of display.
when I run full-screen parallels, create a rio window there,
start equis, all works fine.
http://plan9.cs.utwente.nl/equis-parls2.png
when I have screen-sized parallels window running as window
among other mac windows, with top-left corner somewhere in
the middle of the screen, then create rio window and start
equis I get the slanted stuff.
I tried various times, and the issue is indeed about the
situation at the moment the rio window is created.
that situation seems to be rembered as part of the rio window:
once a rio window is created 'the wrong way', it does not help
to make the parallels window full-screen before starting equis.
it might be possible to see the difference in properties
of the created rio window, if I would known where to look.
when I put the parallels window non-full screen, but with
left border at left border of display, then create a rio window,
then make it full screen again and start equis it worked fine too.
when I move the parallels window to the right, create a rio window,
go full screen and start equis I get the slanted lines.
conclusion:
somehow the horizontal offset between left corner of parallels window
and left corner of display confuses parallels, or plan 9,
or the combination.
also, with the parallels window left-top corner in the middle
of the display, as soon as the fat plan 9 mouse cursor hits the
bottom of the display (or the off-screen bottom of the parallels window?)
a second small mouse cursor (the mac one) appears,
with an offset from the fat plan 9 one. which one is leftmost
depends on the horizontal position of the plan 9 cursor when it
hits the bottom (of display or parallels window, I don't know)
the second cursor disappears again either when it is the first
to go beyond the top or left border of the parallels window,
or when the plan 9 cursor hits such border first, then further
mouse movement pushes the mac mouse cursor to the plan 9 one
till they coincide and the mac mouse cursor disappears.
there is also some interaction with stuff in the dock.
when I see the two mouse cursors and they go low enough
the dock that was hidden at the bottom of the display unhides.
If I only see one mouse cursor that does not happen.
===== drawterm =========================================
bash-3.2$ name of display: slurp:0.0
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 6600
X.Org version: 0.0.6.600
maximum request size: 262140 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 5
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 24, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x60000a, revert to PointerRoot
number of extensions: 4
RENDER
SHAPE
X-Resource
XInputExtension
default screen number: 0
number of screens: 1
screen #0:
print screen: no
dimensions: 837x575 pixels (212x146 millimeters)
resolution: 100x100 dots per inch
depths (6): 1, 8, 16, 24, 32, 32
root window id: 0x35
depth of root window: 32 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 2048
preallocated pixels: black 0, white 16777215
options: backing-store NO, save-unders NO
largest cursor: 837x575
current input event mask: 0xd0001d
KeyPressMask ButtonPressMask ButtonReleaseMask
EnterWindowMask SubstructureRedirectMask PropertyChangeMask
ColormapChangeMask
number of visuals: 1
default visual id: 0x21
visual:
visual id: 0x21
class: TrueColor
depth: 32 planes
available colormap entries: 2048 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
==================================================
===== parallels ===============================
name of display: 10.211.55.3:0.0
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 6600
X.Org version: 0.0.6.600
maximum request size: 262140 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 5
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 24, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: PointerRoot
number of extensions: 4
RENDER
SHAPE
X-Resource
XInputExtension
default screen number: 0
number of screens: 1
screen #0:
print screen: no
dimensions: 604x494 pixels (153x125 millimeters)
resolution: 100x100 dots per inch
depths (6): 1, 8, 16, 24, 32, 16
root window id: 0x35
depth of root window: 16 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 64
preallocated pixels: black 0, white 65535
options: backing-store NO, save-unders NO
largest cursor: 604x494
current input event mask: 0x0
number of visuals: 1
default visual id: 0x21
visual:
visual id: 0x21
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits
=====================================================
thanks, I'm at it.
--
Federico G. Benavento
this is weird, I guess it might be something wrong with the way I use
bytesperline(screen->r, screen->depth), because this only happens
with 16 bpp and with certain windows sizes, that's why I was puzzled,
because it doesn't happen always!
I'll investigate
sorry, but I have no idea what you're talking about, what desktop?
rotating?
> I hope there won't be too much linux apps ported to plan9 in the feature...
I don't get this either.
those are "metacity"'s window effects. gnome's window manager window
manager. don't ask how i know :)
I have run into the same thing running Plan 9 natively on 16-bit color
mode. It seems to be partially a function of the window size/shape
and partially a result of some perverse gremlin somewhere in my
machine; if I keep killing and restarting equis while twiddling window
size, I can eventually get a working display.
John
it has to do with the reminder of some division, I'm fixing it, let me test it
and I'll push it.
thanks
thanks for the bug reports :)
--
Federico G. Benavento
You're welcome.
> > I hope there won't be too much linux apps ported to plan9 in the feature...
>
>
> I don't get this either.
I intended to write future instead of feature, although it could be
feature future.
You're a good man:)
Perhaps my fear is not appropriate yet. Perhaps it evolves the right way.
hah, I don't even have a lunix here, I installed linux in 2002, but that
was long ago.
--
Federico G. Benavento