From: Dave Mielke
Subject: Re: [BRLTTY] HIMS Braille Sense does not work
Date: Mon, 2 Apr 2012 00:32:47 -0400
> [quoted lines by Thomas Fauvel on 2012/04/01 at 18:04 +0200]
>
>>The file dmesg-bs.log is with braille sense.
>
> I believe the earlier conclusion that the Braille Sense is being seen
Pierre Lorenzon wrote:
> But waht shall we do ? Do you
> mind thath it is a probelm of cable as Samuel suggested ? So
> first change de the cable ... second test on another machine
> in case the problem comes from some plug on the computer or
> something deeper. Third bring this Braill
From: Jason White
Subject: Re: [BRLTTY] HIMS Braille Sense does not work
Date: Mon, 2 Apr 2012 17:07:12 +1000
> Pierre Lorenzon wrote:
>
>> But waht shall we do ? Do you
>> mind thath it is a probelm of cable as Samuel suggested ? So
>> first change de the cable ... second test on anothe
[quoted lines by Pierre Lorenzon on 2012/04/02 at 08:50 +0200]
> OK Dave I think I understand. But waht shall we do ? Do you
> mind thath it is a probelm of cable as Samuel suggested ? So
> first change de the cable ... second test on another machine
> in case the problem comes from some plug
charset, hostcmd, and mount have now been split into platform-dependent
packages.
There's now a sys_grub.c, as well as a skeleton grub screen driver.
autogen.sh and configure have now been run. Here are the next set of errors in
my simulated grub build environment that I'd appreciate your thoug
On 02.04.2012 17:33, Dave Mielke wrote:
> charset, hostcmd, and mount have now been split into platform-dependent
> packages.
>
> There's now a sys_grub.c, as well as a skeleton grub screen driver.
>
> autogen.sh and configure have now been run. Here are the next set of errors
> in
> my simulate
As I'm sure you know, configure rejects --host=i686-pc-grub as an unknown
system. Do you know any trick to tell configure to just accept it anyway?
--
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
On 02.04.2012 18:34, Dave Mielke wrote:
> As I'm sure you know, configure rejects --host=i686-pc-grub as an unknown
> system. Do you know any trick to tell configure to just accept it anyway?
Use i386-elf.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP d
What do yo think about just wrapping the problematic #defines with #ifndef? If
we both do that, then it shouldn't matter which config.h is included first. Can
you foresee any problems with doing it that way?
Is it just PACKAGE_xxx that conflict? Maybe the grub environment has no need
for HAVE_x
On 02.04.2012 18:55, Dave Mielke wrote:
> What do yo think about just wrapping the problematic #defines with #ifndef?
> If
> we both do that, then it shouldn't matter which config.h is included first.
> Can
> you foresee any problems with doing it that way?
>
> Is it just PACKAGE_xxx that confl
Since brltty is built with -DGRUB_RUNTIME, what if the grub PACKAGE_xxx
definitions weren't done if GRUB_RUNTIME is defined?
--
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
I've temporarily suppressed the grub PACKAGE_xxx definitioins. Here's the next
error (GRUB_FILE not defined).
configure:17231: gcc -c -g -O2 -std=gnu99 -Wall -ffreestanding -nostdinc
-nostdlib -DGRUB_RUNTIME -I/home/dave/brltty/projects/grub/grub
-I/home/dave/brltty/projects/grub/grub/grub-cor
On 02.04.2012 19:37, Dave Mielke wrote:
> I've temporarily suppressed the grub PACKAGE_xxx definitioins. Here's the
> next
> error (GRUB_FILE not defined).
GRUB_FILE is our analog of __FILE__ more or less. It avoids having long
prefixes.
I've pushed new brltty branch. I attach the patch I did to
On 02.04.2012 19:37, Dave Mielke wrote:
> I've temporarily suppressed the grub PACKAGE_xxx definitioins. Here's the
> next
> error (GRUB_FILE not defined).
>
> configure:17231: gcc -c -g -O2 -std=gnu99 -Wall -ffreestanding -nostdinc
> -nostdlib -DGRUB_RUNTIME -I/home/dave/brltty/projects/grub/g
Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 02 Apr 2012 20:21:51 +0200, a
écrit :
> What do convertCharToWchar and convertWcharToChar do?
Convert from localized 8bit character value to unicode and vice-versa.
Samuel
___
This message was sent via the
On 02.04.2012 20:23, Samuel Thibault wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 02 Apr 2012 20:21:51 +0200, a
> écrit :
>> What do convertCharToWchar and convertWcharToChar do?
> Convert from localized 8bit character value to unicode and vice-versa.
Sounds terribly 8-bit-encoding orien
Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 02 Apr 2012 20:26:00 +0200, a
écrit :
> On 02.04.2012 20:23, Samuel Thibault wrote:
> > Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 02 Apr 2012 20:21:51 +0200, a
> > écrit :
> >> What do convertCharToWchar and convertWcharToChar do?
> > Convert from
On 02.04.2012 20:37, Samuel Thibault wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 02 Apr 2012 20:26:00 +0200, a
> écrit :
>> On 02.04.2012 20:23, Samuel Thibault wrote:
>>> Vladimir 'φ-coder/phcoder' Serbinenko, le Mon 02 Apr 2012 20:21:51 +0200, a
>>> écrit :
What do convertCharTo
[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/02 at 20:07
+0200]
>GRUB_FILE is our analog of __FILE__ more or less. It avoids having long
>prefixes.
But what do I need to do in order to keep going? Is it something I need to
define with gcc's -D option? If so, what should it
[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/02 at 20:21
+0200]
>What do convertCharToWchar and convertWcharToChar do?
Just include charset_none (as opposed to charset_iconv, etc). In charset_none,
they don't do any conversion - they just return the original character.
--
[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/02 at 20:26
+0200]
>Sounds terribly 8-bit-encoding oriented.
Yes. It has historical roots which haven't entirely been eradicated yet.
>Is it used for UTF-8 at all?
Brltty has separate functions for converting between UTF-8 and
On 02.04.2012 21:04, Dave Mielke wrote:
> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/02 at 20:07
> +0200]
>
>> GRUB_FILE is our analog of __FILE__ more or less. It avoids having long
>> prefixes.
> But what do I need to do in order to keep going? Is it something I need to
>
On 02.04.2012 21:07, Dave Mielke wrote:
> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/02 at 20:21
> +0200]
>
>> What do convertCharToWchar and convertWcharToChar do?
> Just include charset_none (as opposed to charset_iconv, etc). In
> charset_none,
> they don't do any conve
Yes, a mkdir() stub setting EROFS would be nice.
Could an access() stub be provided which does open() and close(), and then sets
errno to whatever it was after the open?
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario |
On 02.04.2012 21:43, Dave Mielke wrote:
> Yes, a mkdir() stub setting EROFS would be nice.
>
> Could an access() stub be provided which does open() and close(), and then
> sets
> errno to whatever it was after the open?
This would be a departure from normal access() semantics as it would
return f
[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/02 at 21:47
+0200]
>> Could an access() stub be provided which does open() and close(), and then
>> sets
>> errno to whatever it was after the open?
>This would be a departure from normal access() semantics as it would
>return fa
Now I'm getting a new type of error. It seems that my gcc and grub disagree on
what a wchar_t is.
configure:17236: gcc -c -g -O2 -std=gnu99 -Wall -ffreestanding -nostdinc
-nostdlib -DGRUB_RUNTIME -DGRUB_FILE=__FILE__ -isystem
/usr/lib/gcc/i686-redhat-linux/4.4.4/include
-I/home/dave/brltty/pr
On 02.04.2012 22:13, Dave Mielke wrote:
> Now I'm getting a new type of error. It seems that my gcc and grub disagree
> on
> what a wchar_t is.
>
> configure:17236: gcc -c -g -O2 -std=gnu99 -Wall -ffreestanding -nostdinc
> -nostdlib -DGRUB_RUNTIME -DGRUB_FILE=__FILE__ -isystem
> /usr/lib/gcc/i
[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/02 at 22:17
+0200]
>I think I have fixed this one. You should probably update
I had a "bzr pull" running, actually. It's done now. Do I need to do autogen.sh
or configure again after the pull?
--
Dave Mielke | 2213 Fo
On 02.04.2012 22:22, Dave Mielke wrote:
> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/02 at 22:17
> +0200]
>
>> I think I have fixed this one. You should probably update
> I had a "bzr pull" running, actually. It's done now. Do I need to do
> autogen.sh
> or configure again
On 02.04.2012 22:06, Dave Mielke wrote:
> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/02 at 21:47
> +0200]
>
>>> Could an access() stub be provided which does open() and close(), and then
>>> sets
>>> errno to whatever it was after the open?
>> This would be a departure fro
On 02.04.2012 21:43, Dave Mielke wrote:
> Yes, a mkdir() stub setting EROFS would be nice.
Actually this wouldn't be enough. PID-related functions use sscanf and
this is a difficult function to implement and it isn't needed there if
no write support is available
> Could an access() stub be provided
Your diff for cmds.auto.h is unnecessary. After the "svn update" of brltty, do
"make cmds.auto.h". In general, do make on anything that ends in ".auto.h".
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is
After "bzr pull", "autogen.sh", and "configure", I'm still getting the
conflicting definitions of wchar_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 | Ca
On 03.04.2012 00:02, Dave Mielke wrote:
> After "bzr pull", "autogen.sh", and "configure", I'm still getting the
> conflicting definitions of wchar_t.
I have -D_WCHAR_T_DECLARED=1. Later I'll improve it to use wchar_t from
stddef in GRUB as whole.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenk
There seem to be problems with NESTED_FUNC_ATTR not being defined. What defines
it?
--
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:
On 03.04.2012 00:51, Dave Mielke wrote:
> There seem to be problems with NESTED_FUNC_ATTR not being defined. What
> defines
> it?
config.h. With gcc >=4.5 you can -DNESTED_FUNC_ATTR= (it's here because
of compiler bug)
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Descript
[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/03 at 00:54
+0200]
>config.h. With gcc >=4.5 you can -DNESTED_FUNC_ATTR= (it's here because
>of compiler bug)
:-( I have 4.4.4. Do you know what'd be reasonable to define it to? Would
defining it to nothing be okay?
--
Dave Mie
On 03.04.2012 01:10, Dave Mielke wrote:
> [quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/03 at 00:54
> +0200]
>
>> config.h. With gcc >=4.5 you can -DNESTED_FUNC_ATTR= (it's here because
>> of compiler bug)
> :-( I have 4.4.4. Do you know what'd be reasonable to define it to? Wo
It looks like charset_grub.c hasn't been formally added to the repository as it
isn't in my copy.
Does grub have a way to manage the modem control lines (DTR, RTS), and to query
CTS,DSR? If so, which functions do so, and where are the constants they rely on
defined? As you may have guessed, I'm
On 03.04.2012 01:38, Dave Mielke wrote:
> It looks like charset_grub.c hasn't been formally added to the repository as
> it
> isn't in my copy.
Weird it is there:
http://bzr.savannah.gnu.org/lh/grub/branches/brltty/annotate/head:/grub-core/braille/brltty/Programs/charset_grub.c
>
> Does grub have
[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/03 at 01:52
+0200]
>> It looks like charset_grub.c hasn't been formally added to the repository as
>> it
>> isn't in my copy.
>Weird it is there:
>http://bzr.savannah.gnu.org/lh/grub/branches/brltty/annotate/head:/grub-core/brail
Would you consider adding const to the second argument (serial_port_config*) of
serialPort->driver->configure(), or should I type-cast my way out of the
"assignment discards qualifiers" warning?
Is there a function to turn a grub_err_t into an error message for logging?
--
Dave Mielke
On 03.04.2012 02:27, Dave Mielke wrote:
> Would you consider adding const to the second argument (serial_port_config*)
> of
> serialPort->driver->configure(), or should I type-cast my way out of the
> "assignment discards qualifiers" warning?
I'll add const once it's not middle of the night.
> Is
grub_error() takes a format string. How does the user-supplied string mesh with
the information that the function itself fills in? Are there, for example,
special % characters that fill in different properties of the error?
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Wo
On 03.04.2012 02:43, Dave Mielke wrote:
> grub_error() takes a format string. How does the user-supplied string mesh
> with
> the information that the function itself fills in? Are there, for example,
> special % characters that fill in different properties of the error?
>
It's just like normal
[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/04/03 at 02:49
+0200]
>It's just like normal printf (other than it's translated and additional
>argument at the beginning)
Is there a way to turn the value of grub_err_t into a meaningful string which
can be included within the grub
Should the driver's fini() method be called when we're done with the serial
port? If so, what does it do, and what should we call to open the port?
Can the fetch,put,fini methods fail? Should we be testing grub_errno after
calling any of them?
Is there a list of supported serial speeds?
--
Da
48 matches
Mail list logo
