Bug#760916: brltty interferes with getty autostart
[quoted lines by Michael Biebl on 2016/12/16 at 05:59 +0100] >could you give me an update on this issue? Is this still an issue? No, it isn't. It was fixed almost exactly a year ago. The fix is in brltty 5.4 for sure. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.org/
Bug#760916: brltty interferes with getty autostart
Do either of you know how often systemd-login retries, and how many times it tries before giving up? What we could do is open the vt on demand, and then close it after a timeout of non use. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
There's another case where brltty needs to see a vt when it isn't open. For example, a command can be run asynchronously in a free vt via the openvt command. After the command finishes, the output remains on the vt's screen even though the vt itself has been closed. The user needs to still be able to switch to that vt and read it. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
[quoted lines by Samuel Thibault on 2015/01/22 at 00:46 +0100] Reading is fine, since it's done through /dev/vcsa, which doesn't count in VT_GETSTATE. Not exactly. The tty device still needs to be opened in order to do things like fetch the Unicode map. It's possible, of course, that things like the Unicode map, the screen font map, the character translation table, etc are common to all vts, in which case they could be fetched from tty1. I'm not familiar enough with the internals to know for sure. I noticed a comment in the source for systemd-logind stating that tty1 is special, so using it would seem to be okay. We still need to be sure that all of what we need for mapping the font positions returned by the vcs devices back to the original characters is common to all ttys so that fetching them from tty1 would be valid for other ttys. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
[quoted lines by Dave Mielke on 2015/01/20 at 20:32 -0500] On my Fedora systems - which are managed by systemd - X starts on tty1. As I understand it, X also wants a free vt. Why is it, then, that X is willing to start on tty1 (at least on Fedora systems) even though brltty already has tty1 open? How does X decide that tty1 is still free? -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
[quoted lines by Samuel Thibault on 2015/01/21 at 01:10 +0100] But isn't there still the risk that brltty opening tty1 for this purpose may prevent systemd-login from starting getty on tty1? systemd-login always starts getty on tty1. On my Fedora systems - which are managed by systemd - X starts on tty1. Of course, X doesn't start till later, so, for most of the boot, nothing is running on tty1. Something else to consider is the desire for brltty to start as soon as possible. Ideally, it should be able to start before things like the fscks so that a braille user can manage his own system failures. This, of course, would be way before any getty would be started. I suspect that vt_stat would be 0 at this point, so we either disallow a braille user to deal with early boot problems or we need to dream up some other approach. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
[quoted lines by Dave Mielke on 2015/01/20 at 00:34 -0500] Brltty could delay opening the tty until the user needs to inject a character. This could be by typing on the braille device, by requesting cursor routing, etc. The user probably wouldn't do any of that until the login prompt appears. I just checked. It turns out that brltty actually does need to open the vt right away. For example, it uses GIO_UNIMAP to retrieve the Unicode map so that it can back translate font positions into characters in order to determine what's on the screen. It also uses VT_GETHIFONTMAKS in order to know how to interpret the attributes bytes. Yet another thing it does is use VT_GETSTATE in order to determine which vt is active (vt_stat.v_active). Even open on demand, therefore, would result in the tty being opened almost immediately. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
[quoted lines by Samuel Thibault on 2014/12/29 at 18:30 +0100] We could open it on demand rather than immediately? On which demand? Brltty could delay opening the tty until the user needs to inject a character. This could be by typing on the braille device, by requesting cursor routing, etc. The user probably wouldn't do any of that until the login prompt appears. Whatever the timing, there is a risk that systemd-logind gets slow for some reason, and not manage to start getty before brltty opening it. Perhaps, but the user is unlikely to do much before seeing the login prompt. One way could be for brltty to quickly check from /dev/tty1 with VT_GETSTATE whether some process is actually running on the new VT, before opening /dev/tty0. That will always succeed in normal operation, it will fail when systemd-logind hasn't started getty on the VT yet, thus preventing brltty from opening it. But isn't there still the risk that brltty opening tty1 for this purpose may prevent systemd-login from starting getty on tty1? Another scenario to consider is people who could be emitting data to some VT through e.g. a cronjob. An additional check that brltty could do after VT_GETSTATE would be checking whether /dev/vcsa is a blank screen. In that case, there is indeed really nothing to do with the VT. It could be that such an appliation simply hasn't written any data to the vt yet. In other words, I believe that even a blank screen is significant to the user in such a scenario, and, therefore, he must still be able to read it. Is there no way for brltty to open a tty secretly? -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
Hi: We could open it on demand rather than immediately? -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741136: brltty: Very unstable in Debian Installer 7.4
Hi: getCurrentTime() is no longer being called in async. This is new in 5.0. Perhaps the problem is happening in an older release. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741136: brltty: Very unstable in Debian Installer 7.4
Hi: So do you need me to do anything, or is fixed in 5.0 good enough? -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680638: [BRLTTY] Bug#680638: brltty: Not fully translated preferences menu
[quoted lines by Samuel Thibault on 2012/07/08 at 16:47 +0200] Mmm, this is still marked as fuzzy in the tree, did you perhaps just forgot to remove the fuzzy keywords? It seems so, see attached patch. This patch has now (revision 6588) been committed to brltty's development stream. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of Salvation. EMail: d...@mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680648: [BRLTTY] Bug#680648: brltty: A new accent problem
[quoted lines by Samuel Thibault on 2012/07/07 at 16:17 -0300]
Where is convertTextToWchars called? What I see in the driver in
readCharacters_LinuxScreen() is a call to setScreenMessage which just
uses strlen() and copyScreenCharacterText() without taking charset into
account.
The message being discussed doesn't use that mechanism.
screen.c:1063: problemText = gettext(screen not in text mode);
screen.c:1072: description-unreadable = problemText;
brltty.c:3309: if (scr.unreadable) {
brltty.c:3310: if (!isSuspended) {
brltty.c:3311: writeStatusCells();
brltty.c:3312: writeBrailleText(wrn, scr.unreadable);
brltty.c:296: int
brltty.c:297: writeBrailleText (const char *mode, const char *text) {
brltty.c:298: size_t count = getTextLength(text) + 1;
brltty.c:299: wchar_t characters[count];
brltty.c:300: size_t length = convertTextToWchars(characters, text, count);
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of Salvation.
EMail: d...@mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html
http://FamilyRadio.com/ | http://Mielke.cc/bible/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680648: [BRLTTY] Bug#680648: brltty: A new accent problem
[quoted lines by Dave Mielke on 2012/07/08 at 08:53 -0400] [quoted lines by Samuel Thibault on 2012/07/07 at 16:17 -0300] Where is convertTextToWchars called? What I see in the driver in readCharacters_LinuxScreen() is a call to setScreenMessage which just uses strlen() and copyScreenCharacterText() without taking charset into account. The message being discussed doesn't use that mechanism. I take that back. You're correct. The setScreenMessage() path is indeed being taken (I'll figure out why, later). In any event, setScreenMessage() has now (revision 6587) been converted to use mbrtowc(). Please test. That should've been done a long time ago, anyway. Hopefully, this was the last uninternationalized place in the code (but I'm sure it isn't). -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of Salvation. EMail: d...@mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680648: [BRLTTY] Bug#680648: brltty: A new accent problem
[quoted lines by Samuel Thibault on 2012/07/07 at 14:04 -0300] Jean-Philippe MENGUAL, le Sat 07 Jul 2012 16:04:06 +0200, a écrit : * What led up to the situation? I use brltty running orca on gdm3. * What was the outcome of this action? L'??cran n'est pas en mode texte As it appears to me, the message is being translated correctly except for one letter - the é. Is that correct? If yes, do we know what it's being translated to? If no, can the precise problem be explained more clearly? I've checked, and the translation looks correct within the fr.po file. msgid screen not in text mode msgstr L'écran n'est pas en mode texte It seems that the message returned by the screen driver when the screen is not readable does not get properly decoded by the core. Dave? The code looks correct to me. The screen driver already calls gettext(), so the message as rturned by the screen driver is already translated. Then it gets translated into wchars via brltty's convertTextToWchars(), which is mapped to mbstowcs(). -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of Salvation. EMail: d...@mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680648: [BRLTTY] Bug#680648: brltty: A new accent problem
[quoted lines by Samuel Thibault on 2012/07/07 at 15:10 -0300] If yes, do we know what it's being translated to? é That's what it's supposed to be. I guess I should've asked if we know what it's being mistranslated to? The code looks correct to me. The screen driver already calls gettext(), so the message as rturned by the screen driver is already translated. Then it gets translated into wchars via brltty's convertTextToWchars(), which is mapped to mbstowcs(). Except that the end result is not correct for some reason. Is there a problem if the .po file specifies: Content-Type: text/plain; charset=UTF-8\n but the user isn't using a UTF-8 locale? In other words, I'm theorizing that our translations are stored - and returned - in UTF-8, but mbstowcs() is using the locally-specified system encoding. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of Salvation. EMail: d...@mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475604: brltty: should sort out icu usage
[quoted lines by Mario Lang on 2008/04/14 at 13:21 +0200] Hi: There has been a misunderstanding. --disable-icu will only be used with the installer version of brltty, the full version (which is the one that gets installed into the target system) will not use --disable-icu, and ICU functionality will therefore be available to users in the final system (after they rebooted from the installer into their real system). Its just that libicu is not available in the somewhat stripped down installer environment, and therefore we have to be able to disable its usage in the installer build of brltty. Okay. Thanks for the clarification. I fully understand the need for installers to have minimal environments. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475604: brltty: should sort out icu usage
[quoted lines by Mario Lang on 2008/04/13 at 20:39 +0200] Hi: CC'ed upstream. Dave, the problem is that we do build the installer version and the full version of brltty in one go, so if we request libicu as a build dependency, it will also be available during the installer version is built, but libicu is actually not available at installer runtime. is there any possibility we could get a configure flag for disabling the use of ICU? Yes, that can be done. It's unfortunate, though, to deny the additional functionality to users simply because the installer environment doesn't support it. That seems like a very non-user-friendly constraint. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475604: brltty: should sort out icu usage
Brltty's configure script now supports the --disable-icu option. As stated earlier, though, I consider it unfriendly to withhold features from users based on what the installer's environment is able to support. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359062: debian-installer: bterm is not (yet) accessible for brltty
[quoted lines by Joey Hess on 2006/03/29 at 10:17 -0500] Changing the frontend could be easily done when bterm is started up. How would I, being completely blind and incapable of seeing the screen without my braille display being able to view what's on it, be able to do that? Please have someone else change the screen layout a bit so that you don't know what to expect, and then close your eyes and give it a try. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359062: debian-installer: bterm is not (yet) accessible for brltty
[quoted lines by Samuel Thibault on 2006/03/30 at 01:12 +0200] I'm not blind so my voice might be suspicious, but I find it a lot easier to use the newt frontend than the text frontend: choosing an option in a long newt list is just a matter of pressing arrows, while browsing through the text list is quite tedious. It's always easier to make a selection from a list rather than searching way back for an item, remembering how to type it, and entering it. When I configure a kernel, I use menuconfig. Why? Because it's much, much easier to use than the strictly text-based way. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359062: debian-installer: bterm is not (yet) accessible for brltty
[quoted lines by Samuel Thibault on 2006/03/30 at 01:18 +0200] I forgot to mention that for speakup, the text frontend seems to me much better than newt indeed (that's why it is included on speakup floppies). What works well for speech doesn't necessarily work all that well for braille. Braille gives a full, two-dimensional view of what's on the screen, so a passive way to inspect the whole screen at any time gives the driver the most freedom to let it do its job properly without some other piece of more general software thinking that it knows what's best. The best approach for braille is one which lets the user have full control. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355851: a blindunfriendly debian installer problem
[quoted lines by Samuel Thibault on 2006/03/28 at 11:41 +0200] Hi: However, although it works well when hotplugging the device after bootup, it does not when booting with the device already plugged, because USB seems to be discovered before vcsa nodes are available, hence brltty fails. brltty makes any vcsa devices which it needs but aren't there yet. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355851: a blindunfriendly debian installer problem
[quoted lines by Samuel Thibault on 2006/03/28 at 15:57 +0200] Hi: for some reason it fails here... Maybe udev, while still booting, prevents brltty from being able to create anything in /dev? In my opinion, it's more important to give the blind person his screen as quickly as possible rather than to wait, which would still leave him wondering what went wrong. A better solution, therefore, might be for brltty to make the device file somewhere else, e.g. in /etc/brltty, if it can't create it in the usual place. It could even remove the file immediately after opening it, in this case, if we deem it important to not leave device files lying around in strange places. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359062: debian-installer: bterm is not (yet) accessible for brltty
Hi: I, personally, don't want to see any solution which is Debian-specific, or any other distribution-specific either. The Debian installer uses betrm. So does RedHat when Asian characters are used. So/ probably/ do other distributions. Regardless of what any individual installer does, bterm can also be used at any other time. Any solution which solves the problem for only one particular instance of a general case is, in my opinion, an extremely poor alternative for solving the problem as a whole in one place for all cases. This can easily be done by changing bterm to passively export its view of the screen in a software-readable way. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355851: a blindunfriendly debian installer problem
[quoted lines by Frans Pop on 2006/03/28 at 23:20 +0200] Before init is run? That is where proc is mounted by d-i, right at the very beginning of the boot sequence. That's not generally true of all systems. What is true, however, is that brltty happily uses /proc/bus/usb if usbfs is already mounted there. My sugestion, therefore, is that the Debian installer mount /proc/bus/usb right after it mounts /proc so that it's ready for brltty to use. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359062: debian-installer: bterm is not (yet) accessible for brltty
[quoted lines by Samuel Thibault on 2006/03/28 at 00:13 +0200] Hi: I'm not saying that. I'm seeing that debian-installer uses bterm by default now. Well, fine, but brltty needs to get that utf-8 stream somehow, for being able to display it on braille devices. Where does bterm maintain the unicode knowledge of what's on the screen? Is it in its own memory, or can we read it from a /dev/fb device? -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359062: debian-installer: bterm is not (yet) accessible for brltty
[quoted lines by Samuel Thibault on 2006/03/28 at 00:57 +0200] Hi: In its own memory, which I proposed (in the very first mail of the discussion) to export somehow to brltty, via some /dev/bterm mmap()ed file for instance (very easy to implement in bterm's code: a mere open() then mmap() instead of the current malloc()). Yes, either that or a shared memory segment. That's what brltty wouldf need in order to passively inspect the data. It'd also need a way to ask where the cursor is, what the screen dimensions are, and, optionally (but hopefully) what the highlighting is for each character. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. http://FamilyRadio.com/ | http://Mielke.cc/bible/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
