Subject: Re: Networking strangeness, osi_enet badness ? plus adb_key() operation
From: Takashi Oe (toe@unlserve.unl.edu)
Date: Mon May 08 2000 - 07:56:27 MDT
Hi,
The source archive of Mac OS drivers is:
ftp://ftp.nada.kth.se/home/f95-sry/Public/mac-on-linux//MacOS-drivers/MOL-drivers.000213.sit
Maybe, you can put your VNC code somewhere we can get so that we may try
finding why adb_key() fails in your mol?
Takashi Oe
On Mon, 8 May 2000, Charles McLachlan wrote:
> Before I start moaning I'd just like say a massive thank you to the writers
> of this fine piece of software. Every time I use it I am gobsmacked by how
> wonderful it is.
>
> But...
>
> Situation: B&W MacG3 running a hacked version of Mol-0.9.41 on a precompiled
> kernel I got from Rob Shaw's site (2.2.10 #1 Sat Oct 30 17:55:06 EDT
> 1999 ppc unknown)
>
> I tried running Mol using the x display driver with my DISPLAY
> set to point at my Intel machine, which is running a little endian,
> RGB565 X server. Currently the x driver doesn't byte swap so I got funny
> colours. Also my keyboard didn't work properly (pressing a button didn't
> produce the right keypress)
>
> Problem: as well as the colour problem, networking only worked intermittently
> with lots of "<*> Can't allocate packet datas (143)" messages.
>
> I had a bit of a go at patching the X driver, but then I thought, "X really
> isn't the right protocol for this. What you really want is a nice simple
> protocol designed from the ground up for remotely displaying things quickly and
> efficiently. Something like VNC in fact"
>
> http://www.uk.research.att.com/vnc
>
> Once I'd got the vnc server working (just about) I tried turning on
> networking (disable_osi_enet: no)
>
> Problem: The "<*> Can't allocate packet datas (143)" appeared with even more
> frequency than when running the X version and seemed correlated with mouse
> waggling.
>
> Guess: sheep_net is grabbing the interface (eth0) in it's entirety and
> upsetting other threads that try to use it. Is this a feature? I can quite
> imagine that MOL *needs* to grab the interface in order to properly fool MacOS,
> but I hope that there's some sort of work around.
>
> Also, I grepped for "Can't allocate" in the source distribution but could only
> find it in pci_roms/osi_enet.pcirom and pci_roms/osi_enet.nw, not in any of the
> source files. Where is the source for these roms?
>
> I've looked at the sheep_net source (sheep.c) and have found that
> sheep_net_write will return -ENOBUFS if dev_alloc_skb fails. Is this where the
> "Can't allocate datas" are coming from? What does dev_alloc_skb do exactly? How
> can I stop it failing? Have I got any of this right?
>
> I'm also seeing a slight problem with keypresses. (This may well be my fault
> and might be related to VNC sequencing issues but thought I raise the matter
> just in case anyone else had seen such behaviour)
>
> When I get an VNC keypress I do adb_key(code & ~0x80). On release I do
> adb_key(code & 0x80), exactly as the X driver does. But, Mol doesn't seem to
> act on the key press until another one is made. i.e. after typing "lard" into
> simpletext, "lar" is displayed. Pressing another key ("c" for instance)
> results in the "d" appearing. It's as if Mol is waiting for the next key down
> before acting on the first one.
>
> What is going on?
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Charlie McLachlan
> AT&T Research Lab. Cambridge.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
This archive was generated by hypermail 2a24 : Mon May 08 2000 - 08:02:40 MDT