Hello, Okash Khawaja, le dim. 21 juil. 2019 18:04:31 +0100, a ecrit: > slide 1: What is speakup? > ------------------------- > - piece of software that reads out what's on console and what you type with keyboard It will probably be interesting to mention the two modes: it speaks text as it gets printed by applications, but the user can also use speakup shortcuts to read what was printed by the application and is still visible on the screen. > slide 3: Present > ----------------- > TODO: tty based vs directly accessing ports Yes, that's an interesting point. Before the tty support, the port knocking was obviously posing problems of conflicting with the existing serial drivers, and supporting only legacy serial ports. You can mention that speakup is particular in that it's a purely software driver that needs to operate the serial port. Thus a line discipline, thus what you implemented. > TODO: console content and keyboard snooping done properly You can indeed mention the proper use of console text fetching, and keyboard notification registration. > TODO: what distros ship with speakup? I must admit that I don't know :) You can also mention that proper unicode support was done, so that all languages can now be supported seamlessly. > slide 3: Future > ---------------- > > - move from staging to mainline > - fix bugs > - new features: usb drivers, auto load > - TODO: what else for future? ask mailing list I think there is at least still work to be done for internationalization of speakup messages and such things. > slide 5: Core: > -------------- > - main.c contains speakup core > - main.c + supporting files yield speakup.ko > - upon loading: > - perform some initialisations (spk_vars, add virtual keyboard, initialise an internal representation of every console etc) > - initialise sysfs interface > - register tty ldisc > - synth_init() (TODO: what is this?) It tries to initialize the synths given on the command line. > - speakup kthread (mainly for synth->catch_up() You can explain that speakup uses buffering: keyboard and console notifiers queue stuff to be spoken, and the speakup kthread progressively pushes that to a serial port or the software synthesis. > slide 6: Core - keyboard and vt: > -------------------------------- > [TODO] I'm not sure whether you want to detail much of that. You could make some rehearsal to see whether you will have the time to detail here. Perhaps that's the place for just explaining the buffering I mentioned above. > slide 8: struct spk_syth: > ------------------------- > TODO: reproduce its code here and go through members one by one It would be tedious to cover it all. You can probably just cover it in a few related groups like: probe/release, read_buff_add/synth_immediate/catch_up/flush, is_alive, get_index > slide 9: struct spk_io_ops: > --------------------------- > - struct spk_io_ops That one you can probably cover it all. > slide 12: Software Synths: speakup_dummy: > ----------------------------------------- > - useful for development purposes Yes, that's an important point to make: you don't need an actual synth to do development. > - typical development set up with speakup_dummy: > - qemu with serial port tied to a file on host > - load speakup_dummy with dev param pointing to the serial port It'd be useful that you provide the ready-to-run commands so people can try it out. Samuel _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
