Gregory Nowak wrote: > My main reason for posting is a problem I'm running into when > attempting to use the serial port feature newly added in the latest > version. I am running on a windows xp professional host, and this > problem seems to be happening regardless of the guest operating system > used. I configured the serial port according to the user's manual as > follows: > > VBoxManage setextradata debian "VBoxInternal/Devices/serial/0/Config/IRQ" 4 > VBoxManage setextradata debian "VBoxInternal/Devices/serial/0/Config/IOBase" > 0x3f8 > VBoxManage setextradata debian "VBoxInternal/Devices/serial/0/LUN#0/Driver" > Char > VBoxManage setextradata debian > "VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Driver" NamedPipe > VBoxManage setextradata debian > "VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Config/Location" > "\\.\pipe\vmwaredebug" > VBoxManage setextradata debian > "VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Config/IsClient"
The last line is definitely not from the manual. It is incorrect in several ways. If you want to configure VBox serial line code to be a client for an already running socket server, use VBoxManage setextradata debian "VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Config/IsServer" 0 > Vboxmanage returns no errors after each invocation, and using > getextradata confirms that everything is configured as expected. I am > using the vmwaregateway application mentioned in the manual, and am > attempting to connect virtualbox to the vmwaredebug namedpipe as a > client, that vmwaregateway provides. I have vmwaregateway running in > test mode (with the /T flag) before I start the debian vm. Once I > start the vm, it doesn't power on, and virtualbox displays an error > saying that serial0 cannot attach to char driver. This is all normal, and a result of the incorrect configuration. There is a reason why the serial port stuff is mentioned in section 9 only. The current configuration method is much too difficult and error-prone, but we simply have no time to fix this. > I didn't think it would be appropriate to post the whole log file to > the list. So, if someone from innotek would like me to send the > complete log file to them privately, or if it is ok to post the whole > log to the list, please let me know. Is there something I'm doing > wrong here, or is this a bug which will be fixed in a future release? This is no bug as far as I can tell, it's misconfiguration. If not, let us know. > Like my subject says, I have a few suggestions for improvement as > well: > > 1. Could innotek please consider either implementing the gui interface > to virtualbox as standard windows controls, or exposing components of > the current gui through Microsoft Active Accessibility, so as to make > the gui usable by people such as myself, who access windows using a > screen reader? The screen reader I personally use is called > window-eyes <http://www.gwmicro.com/Window-Eyes>.> I've been able to > make the current gui slightly usable with window-eyes, by tricking it > into thinking the gui custom control is really an mdi window, but > this approach still leaves much to be desired, especially since the > whole gui uses the same class and window style for all controls, thus > making it impossible for the end-user to try to trick window-eyes into > distinguishing the individual controls in the gui interface. > > Gw-Micro has some tips for developers wishing to make their products > usable with screen readers at <http://www.gwmicro.com/Developers/>, > and they are willing to help companies make their products > accessible. If converting to standard windows control is the only way to get it to work with such screen readers, then it's probably nothing that will happen in the short to medium term. The VirtualBox GUI is based on the Qt library (version 3) for portability reasons. The very same GUI source code is used for Windows, Linux, MacOS X and soon other OSes like Solaris and OS/2. It is too much effort to implement a native GUI on each of those platforms. If it's possible to make Qt3 work better with screen readers, then our GUI developers may find some time to implement the necessary changes eventually - but they need information on that. > I have been using computers since the days of DOS, and use gnu/linux > via the text console exclusively (more on this in my second suggestion > below), so I don't mind using the vboxmanage command-line interface, > but there are a couple of things that don't seem to be doable via > vboxmanage, such as changing the host key from the right control key to > another key, or combination of keys, and it would be nice to have the > option of using the gui interface as well. This is possible, but has the same error-prone configuration interface as the serial port. So I don't describe it here. > 2. For my second suggestion, I would like to add my voice to those > asking for access to physical host serial rs232 ports from the virtual > machine. Even if it would be impossible to make this work for all > applications, it would be better to have the feature there, so that it > is usable by those who can use it, than for the feature not to be > there at all. I interact with the gnu/linux text console using a > screen reader called speakup, <http://www.linux-speakup.org>. As of > now, speakup only works with serial-based speech synthesizers, since > the manufacturers of usb speech hardware require a non-disclosure > agreement to be signed, in order to give out specifications for > communicating with their hardware. The way that speakup works > currently, is to probe standard i/o addresses for ttyS0 through ttyS3, > and "steal" the serial port from the linux kernel, if it finds a > synthesizer attached. This means that speakup currently doesn't work > with usb to serial converters, even if these converters use the > generic serial protocol, as opposed to a proprietary protocol. > > What I'm getting at here, is that in order to independently install a > gnu/linux distribution which includes speakup as a guest inside > virtualbox, I would need to have access to a physical host serial port > from inside the virtual machine. It's ok if that port is a usb to > serial converter, as long as it is presented to the guest inside the > vm as a standard serial port. It is true that gnu/linux distributions > can be installed via telnet/ssh, however, this isn't true for all > distributions, notably for slackware and debian. It is also possible > to use speakup via software speech using the pc soundcard, however, > the only distribution to support this currently, officially, or > unofficially, is grml. It would also > be possible to do unattended installations of some gnu/linux > distributions, or to have a sighted person read the screen to the > blind person doing the install, however, these aren't ideal solutions. > > There have been reports on the speakup list of successful > installations using a serial synthesizer to install a distribution of > gnu/linux with speakup as a guest inside of vmware products, (some of > those were done with a usb to serial converter plugged into the host), > and I > myself have been able to successfully use a dos screen reader with my > serial synthesizer inside of Microsoft virtualpc, and I imagine that speakup > would also work, if I were to try installing a gnu/linux guest inside > of virtualpc. In short, being able to access a physical serial port > from the vm would be a great benefit to many people, including those > who are blind, and who wish to install gnu/linux guests inside of > virtualbox independently, using speakup with a serial speech > synthesizer. There is absolutely no technical reason for not providing host serial port support. It's just that we don't have time to do it. The existing code would need a few minor changes for processing the communication parameters and a new backend (very similar to the already existing local domain socket one) would need to be added. We're happily accepting contributions, and such small things really shouldn't be hard for anyone capable of writing code accessing the serial port on Windows without additional libraries. A bonus would of course be a Linux version of the code, too. -- Dr. Klaus Espenlaub innotek GmbH, http://www.innotek.de _______________________________________________ vbox-users mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-users
