Re: usb/179505: Kernel detaches Arduino Leonardo (and similar) board umodem after the arduino boots
The following reply was made to PR usb/179505; it has been noted by GNATS. From: Mike Meyer m...@mired.org To: bug-follo...@freebsd.org, m...@mired.org Cc: Subject: Re: usb/179505: Kernel detaches Arduino Leonardo (and similar) board umodem after the arduino boots Date: Thu, 31 Oct 2013 00:56:21 -0500 --001a11c2903cf874eb04ea031bdf Content-Type: text/plain; charset=ISO-8859-1 This problem is fixed by the the patch in usb/183505. You should probably close this one since the patch is there. --001a11c2903cf874eb04ea031bdf Content-Type: text/html; charset=ISO-8859-1 div dir=ltrThis problem is fixed by the the patch in usb/183505. You should probably close this one since the patch is there./div --001a11c2903cf874eb04ea031bdf-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/183505: [usb] Arduino Leonardo exposes three interface descriptors but no modem is attached to the first one (bInterfaceSubClass=2)
The following reply was made to PR usb/183505; it has been noted by GNATS. From: Mike Meyer m...@mired.org To: bug-follo...@freebsd.org, adr...@freebsd.org Cc: Subject: Re: usb/183505: [usb] Arduino Leonardo exposes three interface descriptors but no modem is attached to the first one (bInterfaceSubClass=2) Date: Thu, 31 Oct 2013 00:56:40 -0500 --001a113485000f71e904ea031dc7 Content-Type: text/plain; charset=ISO-8859-1 I'll confirm that patch the issues I with the Leonardo in 179505. Also with the Due, which I never reported as the behavior was identical to the Leonardo. I've added a comment to that effect to 179505 as well. Thanks! --001a113485000f71e904ea031dc7 Content-Type: text/html; charset=ISO-8859-1 div dir=ltrI#39;ll confirm that patch the issues I with the Leonardo in 179505. Also with the Due, which I never reported as the behavior was identical to the Leonardo. I#39;ve added a comment to that effect to 179505 as well.div br/divdivThanks!/div/div --001a113485000f71e904ea031dc7-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/183505: [usb] Arduino Leonardo exposes three interface descriptors but no modem is attached to the first one (bInterfaceSubClass=2)
The following reply was made to PR usb/183505; it has been noted by GNATS. From: Mike Meyer m...@mired.org To: bug-follo...@freebsd.org, adr...@freebsd.org Cc: Subject: Re: usb/183505: [usb] Arduino Leonardo exposes three interface descriptors but no modem is attached to the first one (bInterfaceSubClass=2) Date: Wed, 30 Oct 2013 17:49:09 -0500 --089e0149ce3626ea1c04e9fd2477 Content-Type: text/plain; charset=ISO-8859-1 This is a duplicate of http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/179505 . We really need to get a leonardo into the hands of someone who knows the USB stack. I've been buried (new job shortly after I reported this). Any chance you can help here? --089e0149ce3626ea1c04e9fd2477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable div dir=3DltrThis is a duplicate of=A0a href=3Dhttp://www.freebsd.org= /cgi/query-pr.cgi?pr=3Dusb/179505http://www.freebsd.org/cgi/query-pr.cgi?= pr=3Dusb/179505/a.divbr/divdiv styleWe really need to get a leona= rdo into the hands of someone who knows the USB stack. I#39;ve been buried= (new job shortly after I reported this). Any chance you can help here?/di= v /div --089e0149ce3626ea1c04e9fd2477-- ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Issues 179505
Any chance I can get someone to look at http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/179505? This was discussed on the list, but sort of tailed off. There is more information in the PR than was ever on the list. Thanks, mike ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
On Fri, Jun 21, 2013 at 12:55 PM, Torfinn Ingolfsen torfinn.ingolf...@getmail.no wrote: On Fri, 21 Jun 2013 10:28:41 -0500 Mike Meyer m...@mired.org wrote: Any chance I can get someone to look at http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/179505? This was discussed on the list, but sort of tailed off. There is more information in the PR than was ever on the list. What code (sketch) are you running on the Leonardo? According to thise page: http://arduino.cc/en/Guide/ArduinoLeonardo the board only has one mikrocontroller, so unless your program (sketch) on the Leo handles the usb communication, there will be none after the board resets. (if my understanding is correct) I just tried BitLashDemo, which uses the umodem connection to provide an interactive shell on the Arduino. Except it won't work on the leonardo talking to FreeBSD, because it disconnects. The sketch shouldn't matter. If I connect it to Linux running on a VBox VM on FreeBSD, everything works as expected, no matter what sketch is running. I've updated the issue to note this. mike ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/179505: Kernel detaches Arduino Leonardo (and similar) board umodem after the arduino boots
The following reply was made to PR usb/179505; it has been noted by GNATS. From: Mike Meyer m...@mired.org To: bug-follo...@freebsd.org, m...@mired.org Cc: Subject: Re: usb/179505: Kernel detaches Arduino Leonardo (and similar) board umodem after the arduino boots Date: Fri, 21 Jun 2013 13:07:25 -0500 In answer to questions asked (and answered) on the USB mail list: It doesn't matter what sketch is installed on the Leonardo - the umodem goes away even if the sketch tries to use it. The sketch doesn't matter if the board is connected to Linux running on a VBox VM on FreeBSD; the umodem device stays attached after the sketch starts. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
Sorry 'bout the extra emphasis there. Anyway, the problem is not *simply* the sketch code. It could be something in the Arduino bootloader violating a USB spec that Linux doesn't care about and FreeBSD does. But mucking about with the user code on the Arudino (i.e. - sketches) doesn't change anything: I get the same behavior whether it's running a trivial Blink demo (pretty much no libraries used at all) or a complete interactive shell: It works as expected when connected to Linux running on a VBox VM, with the umodem device always being present. If I don't connect it to the VM, the umodem device appears when the board is plugged in or reset, then disappears before the sketch starts running. On Fri, Jun 21, 2013 at 1:10 PM, Mike Meyer m...@mired.org wrote: This would help - if I were using the SoftSerial library The arduino sketch code is *not* the problem. Everything works fine if I just connect the board to a VBox runninng Linux, even on a FreeBSD host. On Fri, Jun 21, 2013 at 1:03 PM, Torfinn Ingolfsen torfinn.ingolf...@getmail.no wrote: On Fri, 21 Jun 2013 19:55:42 +0200 Torfinn Ingolfsen torfinn.ingolf...@getmail.no wrote: On Fri, 21 Jun 2013 10:28:41 -0500 Mike Meyer m...@mired.org wrote: Any chance I can get someone to look at http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/179505? This was discussed on the list, but sort of tailed off. There is more information in the PR than was ever on the list. What code (sketch) are you running on the Leonardo? According to thise page: http://arduino.cc/en/Guide/ArduinoLeonardo the board only has one mikrocontroller, so unless your program (sketch) on the Leo handles the usb communication, there will be none after the board resets. (if my understanding is correct) Ok, it seems like there is a bug / misfeature in SoftSerial on the Leo: http://vort.org/2012/05/25/trouble-softserial-arduino-leonardo/ -- Torfinn Ingolfsen torfinn.ingolf...@getmail.no ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Issues 179505
On Fri, Jun 21, 2013 at 4:08 PM, Adrian Chadd adr...@freebsd.org wrote: On 21 June 2013 14:07, Hans Petter Selasky h...@bitfrost.no wrote: I think I have one of these devices at work. I can have a look if I have time next week. Possibly the Arduino needs a fix. Look for so-called spurious VBUS pullup toggling in the software of the Arduino. Considering there's a large number of unfixed Arduinos out there and it works fine on Linux, Windows and FreeBSD, I don't think fix the arduino should be the only solution. Did you mean OSX instead of FreeBSD there? While not really optimal, I'd consider it acceptable if the fix were in software, so that the Arduino IDE's burn bootloader menu entry could be used to fix the thing. But fixing things so it just worked would be better. Thanks, mike ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb/179505: Kernel detaches Arduino Leonardo (and similar) board umodem after the arduino boots
Number: 179505 Category: usb Synopsis: Kernel detaches Arduino Leonardo (and similar) board umodem after the arduino boots Confidential: no Severity: non-critical Priority: low Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Jun 12 02:30:00 UTC 2013 Closed-Date: Last-Modified: Originator: Mike Meyer Release:9.1-releng Organization: Meyer Consulting Environment: FreeBSD bhuda.mired.org 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0 r250692M: Thu May 16 11:14:23 EDT 2013 r...@bhuda.mired.org:/usr/src/sys/amd64/compile/BHUDA amd64 Description: When the Arduino boards provide a umodem device to the host for programming and serial communications with the host from the user software (the software running after boot). The newest boards - starting with the Leonardo - also have the ability to provide a variety of HID devices at different endpoints. The older boards work fine. With the leonardo, the umodem device attaches as the board boots (or resets), and the /dev/ttyU* files are created for it. The device then detaches before or as the user code starts running, meaning the files vanish. How-To-Repeat: Plug a leonardo board into a USB port on your machine. Reset it if needed. As it reboots (the L led will be blinking), you can see the /dev/tty* files appear. They will be gone after the reboot is finished. Fix: I don't have a fix. The board can be programmed by hitting reset shortly before running avrdude (so for now, this is a low priority problem). Release-Note: Audit-Trail: Unformatted: ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/179505: Kernel detaches Arduino Leonardo (and similar) board umodem after the arduino boots
The following reply was made to PR usb/179505; it has been noted by GNATS.
From: Mike Meyer m...@mired.org
To: bug-follo...@freebsd.org, m...@mired.org
Cc:
Subject: Re: usb/179505: Kernel detaches Arduino Leonardo (and similar) board
umodem after the arduino boots
Date: Tue, 11 Jun 2013 23:15:13 -0500
Here's the output of a usbdump filtering for the leonardo device (usb3.4):
14:59:07.733989 usbus3.4
DONE-INTR-EP=0084,SPD=FULL,NFR=1,SLEN=0,IVAL=1,ERR=STALLED
frame[0] READ 0 bytes
flags 0x14 SHORT_FRAMES_OK|PROXY_BUFFER|0
status 0xcb821
OPEN|STARTED|SHORT_FRAMES_OK|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:07.743491 usbus3.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0
frame[0] WRITE 8 bytes
02 01 00 00 84 00 00 00 -- -- -- -- -- -- -- -- ||
flags 0x10 PROXY_BUFFER|0
status 0xea1a3
OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:07.743597 usbus3.4
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=STALLED
frame[0] WRITE 0 bytes
flags 0x10 PROXY_BUFFER|0
status 0xca1a1
OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:07.744495 usbus3.4 SUBM-INTR-EP=0084,SPD=FULL,NFR=1,SLEN=0,IVAL=1
frame[0] READ 9 bytes
flags 0x14 SHORT_FRAMES_OK|PROXY_BUFFER|0
status 0xcb823
OPEN|TRANSFERRING|STARTED|SHORT_FRAMES_OK|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:07.745983 usbus3.4
DONE-INTR-EP=0084,SPD=FULL,NFR=1,SLEN=0,IVAL=1,ERR=STALLED
frame[0] READ 0 bytes
flags 0x14 SHORT_FRAMES_OK|PROXY_BUFFER|0
status 0xeb821
OPEN|STARTED|SHORT_FRAMES_OK|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:07.757332 usbus3.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0
frame[0] WRITE 8 bytes
02 01 00 00 84 00 00 00 -- -- -- -- -- -- -- -- ||
flags 0x10 PROXY_BUFFER|0
status 0xca1a3
OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:07.757472 usbus3.4
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=STALLED
frame[0] WRITE 0 bytes
flags 0x10 PROXY_BUFFER|0
status 0xea1a1
OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:07.767332 usbus3.4 SUBM-INTR-EP=0084,SPD=FULL,NFR=1,SLEN=0,IVAL=1
frame[0] READ 9 bytes
flags 0x14 SHORT_FRAMES_OK|PROXY_BUFFER|0
status 0xeb823
OPEN|TRANSFERRING|STARTED|SHORT_FRAMES_OK|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:07.767974 usbus3.4
DONE-INTR-EP=0084,SPD=FULL,NFR=1,SLEN=0,IVAL=1,ERR=STALLED
frame[0] READ 0 bytes
flags 0x14 SHORT_FRAMES_OK|PROXY_BUFFER|0
status 0xcb821
OPEN|STARTED|SHORT_FRAMES_OK|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:08.628712 usbus3.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0
frame[0] WRITE 8 bytes
00 05 04 00 00 00 00 00 -- -- -- -- -- -- -- -- ||
flags 0x50 PROXY_BUFFER|MANUAL_STATUS|0
status 0xea3a3
OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|CONTROL_ACT|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:08.628845 usbus3.4
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
frame[0] WRITE 8 bytes
flags 0x50 PROXY_BUFFER|MANUAL_STATUS|0
status 0xca3a1
OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|CONTROL_ACT|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:08.628862 usbus3.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0
frame[0] WRITE 0 bytes
flags 0x10 PROXY_BUFFER|0
status 0xca0a3
OPEN|TRANSFERRING|STARTED|CONTROL_XFR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:08.628970 usbus3.4
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
frame[0] WRITE 0 bytes
flags 0x10 PROXY_BUFFER|0
status 0xea0a1
OPEN|STARTED|CONTROL_XFR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:08.641521 usbus3.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
frame[0] WRITE 8 bytes
80 06 00 01 00 00 08 00 -- -- -- -- -- -- -- -- ||
frame[1] READ 8 bytes
flags 0x10 PROXY_BUFFER|0
status 0xea1a3
OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:08.641725 usbus3.4
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0
frame[0] WRITE 8 bytes
frame[1] READ 8 bytes
12 01 10 01 02 00 00 08 -- -- -- -- -- -- -- -- ||
flags 0x10 PROXY_BUFFER|0
status 0xca1a1
OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
14:59:08.641749 usbus3.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
frame[0] WRITE 8 bytes
80 06 00 01 00 00 12 00
Arduino Leonardo issues?
Hello, I'm using FreeBSD for arduino development, and trying to use the newer boards (most notably the Leonardo) has uncovered a problem. In particular, this board uses the ATMega 32u4 as both the main processor and the USB interface, rather than having a dedicated processor for USB. The Arduino software (in this case, actually avrdude) expects to use a tty device to program the controller, and communicate with the software installed on it later. This all works fine on the earlier versions of the arduino hardware, which uses either an ftdi or ulpcom device. With the Leonardo, this devices appears when I plug in or reset the card, but vanishes when the card switchs from running the bootloader to running my code. This is particularly annoying when said code expects to communicate with my freebsd box via that usb port! Since I don't see this behavior if I connect the Leonardo to a VM running Linux - the /dev/tty* device is always present - I assume it's either an issue with my FreeBSD configuration, or a problem in the FreeBSD USB code. Searching both google and the arduino forums don't turn up anything useful. I checked with the maintainer of the Arduino port, and upgraded my system from a 9.1-prerelease to the latest 9.1-releng (svn rev 250692). While this is better - the arduino boards now identify themselves properly - I'm still seeing the same behavior. Can anyone provide a pointer as to what I might look at? Or information I can provide that might help diagnose the problem? Thanks, mike ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB APC ups does not show up after boot
On Fri, 24 Oct 2008 09:42:42 +0300 Andrei Kolu [EMAIL PROTECTED] wrote: FreeBSD 7.1-PRERELEASE #0: Wed Oct 22 23:55:13 EEST 2008 Motherboard: Gigabyte X48-DS4 After boot-up I see messages /var/log/messages: --- Oct 24 09:27:13 testiserver apcupsd[734]: apcupsd FATAL ERROR in bsd-usb.c at line 735 Cannot find UPS device -- For a link to detailed USB trouble shooting information, please see http://www.apcupsd.com/support.html. Oct 24 09:27:13 testiserver apcupsd[734]: apcupsd error shutdown completed --- When I reinsert UPS data cable then ups shows up: --- ugen0: APC Back-UPS ES 550 FW:828.D2 .I USB FW:D2, class 0/0, rev 1.10/1.06, addr 2 on uhub1 --- Restart apcupsd and everything is working just fine. Is it motherboard problem with USB or something is broken in FreeBSD? I get the exact same behavior on a Gigabyte GA-P35-DS3L, running either 7-STABLE from just post 7.0-RELEASE and yesterday. Both are amd64 kernels. Since all my other usb devices behave properly, I suspect it's a quirk in the APC USB implementation. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disabling ulpt for a single device
On Sat, 18 Oct 2008 07:33:18 -0500 Zane C.B. [EMAIL PROTECTED] wrote: Is there any way to disable ulpt for a single device? I have one device that needs to be recognized as a ugen device by hplip, but unfortunately I also desire to keep the ulpt module in place. No. Further, that's not good enough in general - I only have one USB printer, but it's got card readers, and hence gets recognized as a da device, which means no ugen even if I take ulpt out of the kernel, which means hplip won't work with it. The usb2 stack should solve all of this by providing a ugen anyway, but I haven't had time to try it out (the scanner is way down my project list). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keyboard and mouse issues
On Wed, 18 Jun 2008 23:19:46 +0200 Torfinn Ingolfsen [EMAIL PROTECTED] wrote: Hello, On Wed, 18 Jun 2008 14:53:59 -0500 Schlechter, Fred [EMAIL PROTECTED] wrote: The mouse pointer disappears when keys are pressed on the keyboard. The mouse pointer reappears only when the mouse is moved or one of the mouse buttons is pressed. This happens only in the console and AFAIK, this works as designed. And it has been working like that long before 7.0. I really can't say if this is a bug, but it is annoying and this issue did not exist when using a PS2 mouse and keyboard. Are you certain about that? I just tested a few systems here, and all remove the mouse pointer i console when keys are pressed. Some of these systems run FreeBSD 6.x, and one runs 7.0-stable. In the terminal emulators, this is a function of them rather than FreeBSD. For instance, xterm turns off the mouse cursor based on the value of the pointerMode resource; the default behavior is as described above most of the time. Sure enough, setting it to never turn off and starting a new xterm makes it never disappear. Other emulators may well have copied that behavior. The video card driver may get involved as well; if it has a hardware cursor and that's enabled, the requests to turn off the cursor might be ignored. I think I've seen that, but can't be certain. I'm not sure whether the console emulation does this, but it wouldn't surprise me. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
