Bug 189170
| Summary: | [PATCH] [vt] Implement KDMKTONE ioctl | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | fullermd | ||||
| Component: | kern | Assignee: | Aleksandr Rybalko <ray> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | emaste | ||||
| Priority: | Normal | Keywords: | vt | ||||
| Version: | 9.1-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
fullermd
2014-05-01 09:30:00 UTC
Responsible Changed From-To: freebsd-bugs->ray Over to maintainer. Author: ray Date: Tue May 6 13:52:13 2014 New Revision: 265442 URL: http://svnweb.freebsd.org/changeset/base/265442 Log: Implement KDMKTONE ioctl. Submitted by: Matthew D.Fuller <fullermd@over-yonder.net> (original version) MFC: 7 days PR: kern/189170 Sponsored by: The FreeBSD Foundation Modified: head/sys/dev/vt/vt_core.c Modified: head/sys/dev/vt/vt_core.c ============================================================================== --- head/sys/dev/vt/vt_core.c Tue May 6 13:46:36 2014 (r265441) +++ head/sys/dev/vt/vt_core.c Tue May 6 13:52:13 2014 (r265442) @@ -1732,9 +1732,17 @@ skip_thunk: td->td_frame->tf_rflags &= ~PSL_IOPL; #endif return (0); - case KDMKTONE: /* sound the bell */ - /* TODO */ + case KDMKTONE: { /* sound the bell */ + int freq, period; + + freq = 1193182 / ((*(int*)data) & 0xffff); + period = (((*(int*)data)>>16) & 0xffff) * hz / 1000; + if(*(int*)data) + sysbeep(freq, period); + else + vtterm_bell(tm); return (0); + } case KIOCSOUND: /* make tone (*data) hz */ /* TODO */ return (0); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" Is there a possible flaw in the committed version? In the original version, if *data is 0, it would not be used. However, in the committed version, *data is first used in freq = 1193182 / ((*(int*)data) & 0xffff); then checked for 0. If it is 0, the above statement may cause divide-by-zero error. -- Cheers, Henry > Is there a possible flaw in the committed version? Technically, probably not more than the original patch. (x & 0xffff) can still be zero even if (x) is nonzero, after all. It's definitely more a POC than a polished silk purse. I think ideally, it should all be handled in vtterm_bell(), which should be adjusted to take pitch/duration like sc_bell() does on the syscons side. But I ran out of time to investigate that well before digging up what else might need adjusting for that, so I just submitted what I had... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. On Tue, 6 May 2014 23:12:07 -0500 "Matthew D. Fuller" <fullermd@over-yonder.net> wrote: > > Is there a possible flaw in the committed version? > > Technically, probably not more than the original patch. (x & 0xffff) > can still be zero even if (x) is nonzero, after all. It's definitely > more a POC than a polished silk purse. > > I think ideally, it should all be handled in vtterm_bell(), which > should be adjusted to take pitch/duration like sc_bell() does on the > syscons side. But I ran out of time to investigate that well before > digging up what else might need adjusting for that, so I just > submitted what I had... > > > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream. Hi guys! It's done in r265546. Many thanks for your help! WBW -- Aleksandr Rybalko <ray@ddteam.net> State Changed From-To: open->closed fixed. |
