server: move pipe from RedChannel to RedChannelClient

Another cleanup patch, no change to behavior (still one client, and it
disconnects previous client if any).

The implementation for multiple client is straightforward: the pipe
remains per (channel,client) pair, so it needs to move from the RedChannel
that to RedChannelClient. Implementation using a single pipe with multiple
consumers (to reflect different latencies) doesn't fit well with pipe rewriting
that is used by the display channel. Additionally this approach is much simpler
to verify. Lastly it doesn't add considerable overhead (but see the display
channel changes in a later patch for a real place to rethink).

This patch is just technical, changing signatures to reflect the first
argument (oop style) so red_channel becomes red_channel_client. Some places
may seem odd but they should be fixed with later comits where the channels
grow to support multiple clients.

Sound (playback/record) channels are the only ones not touched - this is
consistent with previous patches, since they have been left out of the
RedChannel refactoring.  That is left as future work. (note that they don't use
a pipe, which was the reason for not refactoring).

1 files changed, 1 insertions, 1 deletions

diff --git a/server/smartcard.c b/server/smartcard.c
index a8a7beb8..eda73fe2 100644
--- a/server/smartcard.c
+++ b/server/smartcard.c
@@ -342,7 +342,7 @@ static void smartcard_channel_disconnect(RedChannelClient *rcc)
  * so no mutex is required. */
 static void smartcard_channel_pipe_add_push(RedChannelClient *rcc, PipeItem *item)
 {
-    red_channel_pipe_add_push(rcc->channel, item);
+    red_channel_client_pipe_add_push(rcc, item);
 }
 
 static void smartcard_push_error(RedChannelClient *rcc, uint32_t reader_id, VSCErrorCode error)