forked from eklhad/acsint
-
Notifications
You must be signed in to change notification settings - Fork 0
/
todo
163 lines (151 loc) · 7.71 KB
/
todo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
Things to do in the acsint / acsbridge world.
Some of these tasks make the system more usable;
some simply make the software more palatable to the linux community,
in hopes of submitting it to the kernel.
These are in no particular order.
* Follow the linux coding standards and recommendations,
at least for the two kernel modules.
This process has begun, code is indented,
and other syntax issues have been addressed.
We will need to keep this in mind as we make more changes.
I think we should aim for this summer to submit the modules
for consideration in the staging area.
It's a goal anyways.
* ttyclicks.c cannot sleep between clicks unless you patch the kernel.
The patch is included in this repository, but would not be accepted as is.
They would ask us to change the notifier system,
to pass back a new action code like NOTIFY_SLEEP or some such,
and I'm not sure they would even accept that.
"It's too intrusive, and nobody else wants it."
I use to think we get our infrastructure accepted into the linux core first,
and then submit properly written modules using that structure.
But it's hard to get changes accepted in the heart of the kernel.
So now I think you submit functioning modules into staging,
then say to the community,
"That's kind of an ugly implementation.
These things should really be here in the core.
Here is a patch that fixes it."
Get your foot in the door first, with a module that is perhaps
suboptimal, then, when they are stuck with it,
and they have to maintain it, propose changes to the kernel
itself that makes the entire system better.
So with this mindset, I suggest we submit ttyclicks
without the sleep function; it just spins cpu cycles to do its timing,
and then, when it is part of the kernel, we point out how silly that is
and suggest a change to the notifier system.
The same thoughts apply to the next item.
* Clicks, swoops, and notes should really be handled in keyboard.c,
along side the existing function kd_mksound().
I would add kd_mkclick() kd_mkswoop() and kd_mknotes(),
and then the ttyclicks module would use these functions,
and other modules could use them as well.
This is obviously a better approach,
a centralized suite of functions that generates sounds
through the pc speaker or equivalent.
Obviously better, but we'd have a hard time getting it approved from the get go.
So again, back to my reverse logic -
we submit ttyclicks as is, generating its own noises,
and once it is in staging we point out how silly that design is,
and submit a patch that moves the sound functions back to keyboard.c
where they belong.
* ttyclicks makes a quick high beep for echoed capital letters.
this is ascii, and not international.
Capital n tilde, in Spanish, won't beep properly.
This is probably not vital, but we might want to look at it some day.
* Should we have a module parameter to vary the speed
of the clicks in ttyclicks.c?
It would be course, perhaps one of 10 levels, but better than nothing.
Here are some thoughts on how to do that.
Speed is a number from 1 to 10.
Subtract this from 11 to get a delay value, 1 to 10.
This is the number of milliseconds to wait between clicks.
As mentioned earlier, this waiting is done by a cpu loop or by sleeping in vt.c.
I want the latter to be an option, even if we have to patch the kernel to get there.
So there has to be a way to sleep for n milliseconds.
The current value of n is 4.
#define TICKS_CHARWAIT 4000
If HZ = 250 then we sleep until the next jiffy.
Accomplished by unsigned long timeout = msecs_to_jiffies(4);
If HZ = 1000 then we sleep for 4 jiffies.
If HZ = 100 then we sleep for 2 or 3 jiffies, not sure if it rounds up or down.
Thus the timing is not really what we want.
So if the sleep parameter is set, we should restrict delay to those values
that are an integer number of jiffies based on HZ.
If the math doesn't work out, then the module should printk an error message
and return -1, whence it does not load.
Or maybe printk an error message that the timing is not quite what you want,
then return 0 and load anyways.
So ok, let's say we get past that hurdle.
The cpu timing is no problem, just usleep for that many microseconds.
If sleeping then we have to pass the delay value back to vt.c.
I currently pass back a special number, sleep or not.
So I would instead pass back a range of ten numbers,
sleep for that many milliseconds,
and hope, as I do today, that those magic numbers would
never come up in normal unicode output.
Passing special unicodes back is of course very kludgy,
but I don't think we're ready to hack the notifier system at this time,
which is the right way to do it.
we'll probably submit version 1 without any sleep at all,
since they would prefer we take one step at a time.
* Write bridge methods to provide buffered characters in unicode,
ascii, or iso8859 according to your locale.
Some of this has begun, e.g. getsentence_uc(),
and macros can handle utf8, as the read side of the tty expects,
but there is more work to do here.
setpunc(), replaceword(), etc.
These are basically ascii with iso8859-1 shoehorned in if you need it.
That covers Spanish French German etc, and will do for now.
* The detection of echo in the acsint driver is clunky.
It doesn't work for unicodes, only ascii,
and it presupposes a qwerty keyboard.
If you have another layout like dvorak it won't work at all.
I tried KBD_KEYSYM and that didn't seem to work at all.
Catching KBD_UNICODE events looks perfect, but my system doesn't
throw those events; I have no idea why.
This is an open issue.
* Same issue applies to acs_keystring() and acs_get1key() in the bridge.
These assume ascii qwerty, and won't work properly otherwise.
* Maintain a table of row mappings for screen memory.
Example, since last time you refreshed, row 7 has moved up to row 5.
This could happen if the screen scrolled up twice,
because two lines were printed.
But portions of the screen can scroll separately, and they can scroll down instead of up.
The vt notifier throws these scrolling events, and my Jupiter software
catches them, and moves your reading cursor accordingly.
(Perhaps speakup does too.)
An adapter, running in screen mode, needs this functionality,
and the acsint driver / bridge does not offer it today.
I am imagining an array of 25 ints,
telling where each line has moved to since our last refresh.
When this information passes down to the bridge,
it can move your reading cursor appropriately,
and any other markers that are tied to the text in screen memory.
* Fold espeak into the bridge in a seamless fashion.
That is, set ss_style = SS_STYLE_ESPEAK,
and then the ss functions:
ss_shutup
ss_setvolume
ss_incspeed
ss_say_string
etc will just work.
This is more complicated than supporting various models over a serial port,
because it involves function calls to the espeak library,
a library that I would rather not load if it is not needed.
This can be done by conditional compilation, perhaps from a configure script
that defines ACS_ESPEAK as needed.
Another approach is to build an espeak synthesizer client
that makes all these espeak calls, but is a separate program.
It has the same interface as the DoubleTalk, for instance,
which is easy to program.
So the bridge would set ss-styel = SS_STYLE_DOUBLE,
but instead of talking to an external unit over a serial port,
it talks to an espeak synthesizer over pipes,
and the espeak synthesizer converts the doubletalk commands into espeak library calls.
I can't tell, at this point, which approach is better.
But I do know we need some way for an adapter to use all the ss functions
in the bridge, even when those functions control espeak or some other software
synth that is library based, rather than streaming commands
over a serial port or pipe or socket.
* Just before submission, move acsint.h and ttyclicks.h into include/linux,
and use the include style #include <linux/foo.h>