Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 May 2002 19:48:27 +0200
From:      Gerhard Sittig <Gerhard.Sittig@gmx.net>
To:        freebsd-stable@freebsd.org
Subject:   Re: buffer size
Message-ID:  <20020508194827.Z1494@shell.gsinet.sittig.org>
In-Reply-To: <20020507102647.GZ1761@dru.dn.ua>; from admin@dru.dn.ua on Tue, May 07, 2002 at 01:26:47PM %2B0300
References:  <20020501164552.GA34873@dru.dn.ua.lucky.freebsd.stable> <20020507131256.C98604-100000@atlantis.dp.ua> <20020507102647.GZ1761@dru.dn.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
[ The message I reply to had a broken attribution.  So I
cite two single paragraphs to get the history back. ]

Here is what I (Gerhard Sittig) wrote in the thread:
> 
> src/sys/dev/syscons/scmouse.c dynamically allocates the cut_buffer
> array and computes the cut_buffer_size from the screen coordinates.
> So the buffer should be able to hold the whole screen's content.  Do
> you change the screen's dimension after using the clipboard?

On Tue, May 07, 2002 at 13:26 +0300, Vladislav V. Zhuk wrote:
> 
> On Tue, May 07, 2002 at 01:18:22PM +0300, Dmitry Pryanishnikov wrote:
> 
> >  More specifically, it copies no more than 1024 characters (tested both
> > on 4.2-RELEASE and 4.4-RELEASE (fill one of your virtual consoles with text,
> > then select all screen, then switch to another console, start "cat >file"
> > and paste the text, then press ^D twice - you'll see that file size will be no
> > more than 1024).
> 
> I know about this. I asked when this bug will be fixed?
> Who can do it?

Simple question:  Do you (does somebody else) have a fix
available?  If not, do you feel like researching the problem
(you obviously run against the limit and can see if your
modification fixes things for you and maybe others) and
providing a solution by submitting a PR?

To help you to helping yourself:  Did you have a look at
the above mentioned scmouse.c source file, especially its
sc_alloc_cut_buffer() routine?  I just had a look at rev
1.12.2.3 (was -STABLE at the end of March and still should
be the current rev IIRC).  And I cannot see where the limit
you experienced should come from.  Except when the used
M_DEVBUF type has an artificial limit.  But the malloc(9)
manpage doesn't give a hint towards this and even more
suggests that the whole "size" bytes could be allocated
when non NULL pointers are returned.  And I don't believe
in the artificial 1K limit in the kernel's malloc() function
(`vmstat -m` has bigger buckets as well).

I would guess that the 1024 byte limit you mention above is
located somewhere else.  It could be some timing issues (I've
seen terminals being overwhelmed when you "type this fast")
or pipe dimension.  Did you try some `wc` on the pasted
text?  Did you syslog() or printf() the malloc() parameters
in sc_alloc_cut_buffer()?  Did you look at the sc_paste()
routine if p (the cut_buffer) holds all the data, count
characterizes them well but the l_rint callback doesn't take
them all or the rmap table does something weird?  (Although
a quick look at syscons.c makes me think the latter questions
are pure speculation.)


The only bug I would expect in the sc_alloc_cut_buffer() logic
is that when you fill the whole screen (menus?  windowed UIs?)
and put all the content _plus_ the newlines into the cut buffer,
you cannot hold all the data in a buffer of the screen's
dimension.  So the size calculation (in the "do I have to
reallocate?" test as well as in the "so many bytes is what
I need" determination) maybe should read

  cut_buffer_size = (scp->xsize + 1) * scp->ysize + 1;

So the buffer could hold
- all the characters which fit on one line plus the newline
- times the line count in height
- plus the terminating NUL character for the C string


But apart from all of this I get the feeling that you misuse the
clipboard in some way when you have the need to copy (almost)
whole screens.  Are you actually looking for some screen shot
software (like vidcontrol(8)'s -p or -P and the scr2txt or
scr2png converters) or a file transfer utility? :)


virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
Gerhard Sittig   true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
-- 
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020508194827.Z1494>